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Preface 


The Library Development Guide describes creating and 
maintaining libraries. This guide is intended for use by 
the System Librarian and/or Library Developer. The Li- 
brary Developer is responsible for maintaining and 
modifying all libraries and creating new libraries. Valid 
recommends that the Library Developer have the follow- 
ing qualifications: 


e Knowledge of a system text editor 


e Understanding of SCALD language 
concepts 


e Operating knowledge of any Valid 
application necessary to create required 
component models and the ability to 
interpret the application results: 

GED 
ValidPACKAGER 
ValidCOMPILER 
ValidsIM 
ValidTIME 
Transcribe 


vi 


Valid recommends that you give some consideration to 
library development decisions that are pertinent to your 
site requirements. Some of the issues you should 
resolve: 


e Are you developing mil-spec or standard 
components? 


e What body standards should you follow? 


e What are the minimum test procedures for a 
completed component? 


e What is the minimum size for a body or the 
text included with a body? 


e Are you using ANSI or commercial 
components? 


e What tools are you currently using? What 
tools will you be using in the future: Timing 
Verifier, Simulator? Should you save time by 
creating models now for tools you might use 
in the future? 


e Will users be developing their own compo- 
nents or will the Librarian be the only devel- 
oper? Will the Librarian test user-developed 
components? 


The standards used in this manual are for commercial 
components. If you are building ANSI library compo- 
nents, you should follow the standards designed for 
ANSI components. 
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Several Valid manuals are helpful during the library de- 
velopment process. Valid recommends that the Library 
Developer have access to the following documentation: 


Library Development Guide 
Library Reference Manual 
ValidCOMPILER Reference Manual 
ValidPACKAGER Reference Manual 
ValidSIM Reference Manual 
ValidTIME Reference Manual 
SCALD Language Reference Manual 
Tutorial I: Logic Design 


Tutorial Il: Using your Validation Designer 


vii 


The Library Development Manual covers the following 


topics: 

‘Section qT: Library conventions and syntax issues; 
library organization; library maintenance. 

Section 2: Creating library components. 

Section 3: Creating the physical model. 

Section 4: Creating the simulation model. 

Section 5: Creating the timing model. 

Section 6: Creating support components. 

Section 7: Testing a new library. 


Appendix A: Text file method of creating a library 
drawing. 


Appendix B: Changes in the library drawing method. 
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Library 
Fundamentals 


This section discusses: 
e Library development process 
e Library conventions 
e Signal name syntax 
e The library directory 
® The master library file 
e Library components 
e Component versions 
e Operating system considerations 


e Maintaining libraries on foreign hosts 
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The Library 
Development 
Process 


Section 6 discusses creating 
support components. 


There are several steps involved in creating a new 
library and new components. The section of this 
manual that contains further information on a proce- 
dure is noted beside each step. 


1 Build a body drawing. (Section 2) 
2 Create a physical model. (Section 3) 


3 Create a simulation model (if required). 
(Section 4) 


4 Create a timing model (if required). 
(Section 5) 


5 Test the components. (Section 7) 


6 Update the master library file. (Section 1) 


When designing components, some decisions must 
be made about how to assign values that are not 
specified in the data sheets. The librarian must de- 
cide what values are to be used and then must main- 
tain consistency for all components in the library. 
Such decisions should be documented in a file 
placed in the directory so that other users of the 
library can read them. 


As a general rule, permissions on component mod- 
els (body drawings, simulation models, and timing 
models) are set so that only the librarian or root has 
permission to change the models. 
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Library 
Conventions and 
Syntax 


Conventions 


Signal Name Syntax 
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Library conventions and syntax affect how model 
descriptions are entered for all libraries. The Valid 
libraries conform to the following conventions and 
syntax. 


Conventions govern, to a large extent, the shape of 
bodies in the libraries and how signals are named. 
Conventions have far-reaching scope and affect all 
libraries and all designs made with those libraries. 
Global conventions must be decided on prior to pur- 
chase or installation. Many conventions are deter- 
mined by corporate policy; others are determined by 
the user. 


Signal names contain information about the signal 
condensed into a very short space. Library models 
use signal names to convey information and to cor- 
rectly model parts. As a consequence, the designer 
must follow the same syntax used in the libraries. 


Valid supports five different signal syntaxes. These 
are referred to as Library Formats 1 through 5. 
Only one syntax or library format can be used at a 
site. 


Library Format 1 is the Valid standard library for- 
mat. A signal name in Format 1 consists of five 
fields in the following order: 


negation name subscript assertion general_properties 


Library Fundamentals 


For more information on 
signal syntax and a de- 
scription of each Library 
Format, see the SCALD 
Language Reference 
Manual. 


The five library formats vary in four respects: 


e The order of the five fields 


e The bit ordering convention (left-to-right or 
right-to-left) 


e The characters used to indicate low and high 
assertion 


e The character or characters used to indicate a 
bit subrange 


It is important to decide on a Library Format before 
on-site installation. The signal syntax in use at any 
given site is defined in the config.dat file. Table 1-1 
gives the location of this file on the various 
platforms. 


Table 1-1. Config.dat File Locations 


"Platform File Location 


DECstation 
PC AT 
SCALDsystem 
Sun 


VAX 


If the analysis programs 
are to run on a VAX 
mainframe, then an 
identical config.dat file 
must reside on the host. 


/usr/valid/lib/config.dat 
/u0/scald/config.dat 
/u0/scald/config.dat 


/usr/valid/lib/config.dat 


SCALD$ROOT: [LANGUAGE]CONFIG.DAT 


Signal syntax is often set by predefined company 
standards. If your company has no standard, we 
Suggest you use the Valid standard library format 
(Library Format 1). Examples in the documentation 
assume Library Format 1 unless specified otherwise. 
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_Librarv A library consists of a main directory with subdirec- 

. : tories for each component in the library. All of the 
Or ganization Valid-maintained libraries on your system have a 
similar structure. Any library you create will also 
have a similar structure. 


The Library All of the Valid-supplied libraries are installed in a 

Directory single library directory. Table 1-2 defines the loca- 
tion of this directory on each of the Valid-supported 
systems. 


Table 1-2. Library Directory Locations 


| Host ——s|_— Directory Location 


DECstation _ /usr/valid/lib 
PC AT /u0/lib 


SCALDsystem /ud/lib 
Sun /usr/valid/lib 
VAX SCALDS$ROOT: [LIBRARIES] 


Figure 1-1 shows the structure of a typical Valid- 
supplied library directory. 
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——— 
{Library directory} 


tutorial , standard | master. lib 


OlHlH| Allo 


xmplfchttriprt | 20° | ttoriallibrary tutorial. lib 


WA _(SCALD 


Directory) 


ony oD CD CD) esr >OD 


body.1.1 sim.1.1 time.1.1 part.1.1 
body.2.1 sim.2.1 time.2.1 part_cn.1.1 


Figure 1-1. Contents of a Typical Library Directory 
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When you list the contents of the library directory, 
you see the name of each Valid library installed on 
your system and a few other files and directories. A 
sample listing of the contents of the library directory 
is shown in Figure 1-2. 


discrete master.1lib standard time 
fast memory sttl tutorial 
lsttl sim phantom ttl 


Figure 1-2. Contents of Sample Library Directory 


Individual Libraries Each individual library is stored in a directory bear- 
ing its name. For example, the tutorial library re- 
sides in the directory: 


DECstation/Sun: /usr/valid/lib/tutorial 
SCALDsystem: /u0/lib/tutorial 
VAX: SCALD$ROOT: [LIBRARIES] TUTORIAL. DIR 


In addition to the subdirectories containing the com- 
ponent drawings, a library directory may contain 
these additional directories and files: 


e Two reference drawing directories. The draw- 
ing called “EXAMPLE OF EACH ...” includes an 
example of every version of every part in the 
library. It is primarily for documentation pur- 
poses. The drawing is also useful for testing 
the models for the library since, when used in 
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These drawing names are 
abbreviated within the 
operating system. 


a compilation, it invokes all versions of all of 
the parts. 


The other reference drawing includes the first 
version of every part in the library. This draw- 
ing usually has the same name as the library 
(for example, the “TUTORIAL LIBRARY” draw- 
ing). It can be used for library development. 


A SCALD directory. The extension .Jib is re- 
served for library SCALD directories (for ex- 
ample, /sttl.lib). This file contains the map- 
ping between GED drawing names and their 
corresponding operating system directory 
names. 


A physical information file. The optional .prt 
file contains physical information about each 
part in the library. It may be used by the 
Packager and by the interface programs. 


A log file. Each library has a log file of all 
updates made to the library since its initial re- 
lease. The log for Valid libraries is main- 
tained by Valid personnel and is in reverse 
chronological order. 


Figure 1-3 shows a listing of the contents of the tu- 
torial library directory on the UNIX operating 
system. 
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Figure 1-3. 


The Master Library 
File 
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exor tutorial.lib 
inv tutorial.prt 
log xmplfchttriprt 
ttoriallibrary 


Contents of the Tutorial Library (UNIX) 


The names of the drawing files are not exactly the 
same as the GED drawing names because of operat- 
ing system limitations. The algorithm used to create 
file names acceptable to the operating system: 


e@ Removes any spaces or special characters 


e Shortens the drawing name to a maximum of 
14 characters by selectively eliminating char- 
acters (beginning with vowels) 


e Makes each name unique 


The GED name-to-operating system name mapping 
is done automatically by the SCALD directory file. 


The master library file (master.lib) resides in the top 
library directory. It contains the name of each li- 
brary on your system and the full path to that li- 
brary. Adding a library entry to the master.lib file 
allows users to access that library. 


The GED command library looks in the master li- 
brary file for the full path to the specified library. 
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For instance, listing the LSTTL library in the 
master.lib file allows you to enter the command: 


library lsttl 


If there is no entry, you would have to enter the 
entire command line each time: 


lib /usr/valid/lib/isttl/lstt1l.1lib 


A library can reside anywhere on the system as long 
as it is listed correctly in master.lib. When you have 
problems accessing a library, check the master li- 
brary file and see if the library is listed. 


It is not necessary to The last thing you must do after you create and test 

pr the arenes a new library is to update the master.lib file. Use a 

file if eects text editor to access the file, and add an entry for 

an existing library. ; : rae . 
the new library that lists the abbreviation for the li- 
brary and the full path to the library. 


Figure 1-4 shows a sample master.lib file on the Sun 
or DECstation system. The last entry adds the 
“userparts” library to the list of libraries that can be 
accessed on this system. 


file type = master_library; 

‘time’ “’/usr/valid/lib/time/time.lib’; 

“sim’ ’/usr/valid/lib/sim/sim.1lib’; 

‘standard’ ’/usr/valid/lib/standard/standard.lib’; 


‘tutorial’ ’/usr/valid/lib/tutorial/tutorial.lib’; 
“lsttl’ ‘’/usr/valid/lib/1lsttl/lsttl.lib’; 
“userparts’ “’/usr/valid/lib/userparts/userparts.lib’; 


Figure 1-4. Sample Master.lib File 
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Library Components 
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component.BODY 


component.PART 


component.siM 


component. TIME 


A library component consists of a collection of draw- 
ings that together define the part. Within GED, each 
drawing has the same name and a different exten- 
sion. The drawing names in GED are: 


This drawing defines the shape, pins, and general 
properties of the library component; it is the sym- 
bolic representation of the part. When you add a 
library part to a drawing, the .BODY drawing ap- 
pears on the screen. The .BODY drawing may repre- 
sent an actual physical component, or it may repre- 
sent a block of logic. 


The .PART drawing tells the Compiler that this com- 
ponent (body) is a low-level drawing that is added 
to logic drawings. This drawing contains a 
DRAWING body and its attached properties that de- 
fine the physical component name for the Packager. 
When the Compiler compiles for “logic,” it includes 
the global part information from the .PART drawing 
for each body on your drawing. This information is 
then passed on to the Packager. 


This drawing defines the simulation model for the 
library component. When the Compiler compiles 
for “sim,” it includes the corresponding simulation 
model contained in the .SIM drawing for each body 
on your drawing. This information is passed to the 
Logic Simulator. 


This drawing defines the timing model for the li- 
brary part. When the Compiler compiles for 
“time,” it includes the corresponding timing model 
contained in the .TIME drawing for each body on 
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your drawing. This information is passed to the 
Timing Verifier to check the timing behavior of the 
entire design. 


When you list the contents of a component direc- 
tory, the drawing files appear as shown in 
Figure 1-5. 


body.1.1 part _bn.1.1 sSim.1.1 time.1.1 
body.2.1 part_cn.1.1 sim_bn.1.1 time_cn.1.1 
chips _prt part_dp.1.1 sim_dp.1.1 time_dp.1.1 
part.11 phys_dat 


Figure 1-5. Contents of Sample Component Directory 


Additional Files Besides the four component drawings, a library com- 
ponent directory contains these additional files: 


e A chips_prt file. This file contains all the 
physical information for a component. The 
chips_ prt file is used by the Compiler and by 
the section and pinswap commands in GED. 
(It may also be used by the Packager.) It 
allows you to preassign pin numbers to a 
component during schematic creation. 


e A phys_dat file. This is an optional file used 
as input to a special program which can be 
used to create the chips_prt files. This file 
appears in some Valid libraries; these librar- 
ies may use a different procedure for modify- 
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If disk space at your site is 
at a premium, the binary 
files can be deleted. GED 
can recreate any drawing 
from the ASCII version of 
the files. 


There are some exceptions 
that require a logic drawing 
in a component directory. 


10/1/89 


ing physical information than do libraries 
without phys_dat files. See Appendix A for 
additional information on phys_dat files. 


e The binary files (part_bn.1.1, sim_bn.1.1, 
time_bn.1.1). These files contain the same in- 
formation as the ASCII version of the draw- 
ings, stored in a slightly different format. 


e The connectivity files (part_cn.1.1, sim_cn.1.1, 
time_cn.1.1). These files contain the logical 
net lists for the Packager, Simulator, and 
Timing Verifier. 


e The dependency files (part_dp.1.1, sim_dp.1.1, 
time_dp.1.1). These files list each part used 
in the drawing and its library directory. This 
file is used by the GED update facility to en- 
sure that the parts in the drawing are current. 


Notice that there is no .LOGIC drawing in the compo- | 
nent directory. Library components do not normally 
have logic drawings because components are the 
lowest-level drawings that are added to logic draw- 
ings. In flat designs, logic drawings are made up 
entirely of library components connected together. 
In hierarchical designs, logic drawings can be made 
up of library components and symbols representing 
other logic drawings connected together. 


Library Fundamentals 


Component Versions 


If a version is not speci- 
fied, drawing version 1 
is used by default. 


The version number for a 
logic drawing should always 
be “I.” The page number 
for a .BODY drawing 
should always be “1.” 


Many library parts have more than one body draw- 
ing to represent a part. Each of these body drawings 
is called a version. The version number is defined by 
the first digit following the drawing name extension 
(the third field in the name). The version command 
in GED selects which version of a part is used. 


For example, there are two versions of the LS377 
part in the LSTTL library: LS377.BODY.1.1 and 
LS377.BODY.2.1. Figure 1-6 shows the two versions 
of the LS377 component. 


VERSION 1 VERSION 2 
(LS377. BODY. 1.1) (LS377. BODY. 2. 1) 


Figure 1-6. LS377 Versions 1 and 2 


This is Valid’s convention 
for defining body versions. 
You are not restricted to 
these conventions. 


| The Version 1 body drawing usually shows just one 


representative section of a package. The Version 2 
body drawing typically shows all of the sections. (In 
the case of a simple gate, the second version usually 
shows the DeMorgan equivalent of the gate.) 
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The Version 1 Drawing 


For more information 
on the SIZE property, 
see Section 2. 


The Version 2 Drawing 


See the PIN.NUMBER 
portion of Section 3 for 
more information on 
asymmetrical components. 
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Because all sections of the LS377 are identical to 
each other, the Version 1 body can be used to 
represent: . 


e One section of a package 


e Many sections of one or several LS377 
packages 


The Version 1 drawing of the LS377 is called a 
sizeable body. The drawing can be used to represent 
multiple sections by using vectored signal names 
and attaching the SIZE property to the drawing (after 
it has been added to a GED logic schematic). 


The Version 2 drawing of the LS377 more closely 
resembles the physical package of an LS377. The 
LS377 package contains eight identical sections, and 
the Version 2 drawing shows eight input pins and 
eight output pins. The Version 2 drawing is used for 
flat designs. 


In most cases, the two body versions must have 
equivalent pin names. An exception to this rule oc- 
curs in parts with asymmetrical sections. In this 
case the versions of the part that represent the dif- 
ferent sections must have no identical pin names, so 
that the different sections can be distinguished. Ad- | 
ditionally, there must be a property attached to each 
section identifying the section. The Valid conven- 
tion is to name this property “section” and to give 
the property a value that identifies the section num- 
ber of the part to which the body corresponds. 


Some simple logic gates have versions (the DeMor- 
gan equivalents) that represent the two different 
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Version 1 


Version 3 


Figure 1-7. 


logical functions performed by the gate depending 
on the polarity of the input signal. An LSo8, for 
example, performs an AND of high-asserted signals 
or an OR of low-asserted signals. The versions of 
the LS08 allow the designer to add either form of the 
gate to a drawing. 


If a part has sections that are not interchangeable 
(such as the LS51), then there are additional ver- 
sions that describe the additional sections. 
Figure 1-7 shows the different sections of the LS51 
component. 


Version 2 


Version 4 


The LS51 Asymmetrical Component 
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Library 
Maintenance 


Operating System 
Considerations 


Disk Space 


Table 1-2 on page 1-5 
lists the library directory 
for each system. 


UNIX/ULTRIX: 
VMS: 


UNIX/ULTRIX: 
VMS: 
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The System Librarian must be very familiar with the 
SCALD system, the SCALD Language, and logic de- 
sign. The librarian also needs to be reasonably con- 
versant with the host’s operating system and text 
editor. Maintaining libraries requires considerable 
caution since an error in a library affects many users 
and many designs (including completed designs). 


There are two important issues to consider for 
libraries: disk space and file protection. 


All libraries are stored in the library directory. 
There must be enough space in the directory for the 
libraries plus enough space left over for the users. 
For Valid-supplied libraries, the library space re- 
quirements are indicated in the individual library 
descriptions. 


To determine the amount of space required for a 
user-created library: 


1 Change directories to the library in question. 


2 Determine how much directory space is used: 
du -s 
DIRECTORY/SIZE/GRAND_TOTAL [... 

3 Determine the amount of free space on the 

disk: 
df 
SHOW DEVICE DUAO 
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The amount of disk space 
required varies depending 
on the size and complexity 
of a user’s designs. 


Protection 


UNIX/ULTRIX: 
VMS: 


UNIX/ULTRIX: 
VMS: 


Files: 
Subdirectories: 


The disk usage commands show the number of free 
blocks on /u0 or /usr and DUAO, respectively. Leave 
enough disk space for users to work with after the 
libraries are installed. If installing a given library 
results in fewer than 1000 free blocks, you should 
either remove some files from /u0, /usr, or DUAO, not 
install the library, or acquire more disk space. 


The libraries and their directories should be write- 
protected for everyone except the librarian. The 
files in the library should be owned by lib or system. 
Check library ownership by typing: 

ls -l 

DIRECTORY /OWNER/ PROTECTION 
If there are any files not owned by lib or system, you 


can fix this by logging on as root or system, chang- 
ing your directory to the library in question, and 


typing: 
find . -exec chown lib {} \; 
SET DIRECTORY /OWNER=SYSTEM 


In VMS, respond to the “Directory” prompt with: 
axed 


The /s -/ and DIRECTORY/OWNER/PROTECTION com- 
mands also show the permissions of all of the sub- 
directories and files in the library directory. 


With UNIX/ULTRIX systems, the correct permissions 
should be: 


-rw-r--r-—- 
drwxr-xr-x 
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This protection allows the user (which should be lib) 
to read and write the files, but allows everyone else 
only to read the files (UNIX/ULTRIX directories must 
have execute permission set in order to look inside 
the directory). If either the “group” or “other” write 
permissions or both are set (for example, 
-fw-rw-r-- or -rw-r--rw-), write permission 
should be removed by logging in as lib (since “lib” 
owns all the files), changing your directory to the 
library in question, and typing: 


find . -exec chmod go-w {} \\%*; 


With VMS workstations, the correct permissions 


should be: 
Files: RWED,RWED,R,R 
Subdirectories: RWED,RWED,RE,RE 


With these protections, only the system and owner 
can read and write files; everyone else only can read 
the files. If either the “group” or “world” write or 
delete permissions are set (for example, 
RWED,RWED,RWE,RW), change the permission by 
logging in as system and typing: 


SET PROTECTION=(G:R,W:G) *.DIR/LOG 


Maintaining Libraries | If you work on a foreign host such as a VAX main- 

on a Foreign Host frame, keep a copy of the libraries on this machine. 
Otherwise each user must keep a private version of 
the libraries, which wastes disk space. These librar- 
ies should be kept in a read-only directory. 
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See the filecopy utility 
in the System Utilities 
Reference Manual for 
details. 


report files on; 


To copy libraries to or from the foreign host, use the 
filecopy utility. You should run filecopy without a 
transfer.log file when copying libraries to ensure that 
all libraries are on the host. The transfer takes sev- 
eral minutes. 


On the VAX mainframe, each library is stored in a 
directory under [SCALD.LIBRARIES]. Before you 
transfer the libraries, log in to the VAX and create a 
directory for each library you want to transfer. 


For example, for a library named Diblio, create the 
directory [SCALD.LIBRARIES.BIBLIO] on the VAX. The 
filecopy.cmd file would include the following 
directives: 


copy_file ’biblio.prt’; 
directory “biblio.1lib’; 


host_kind VMS; 
host_destination ’/dev/vms/scald/libraries/biblio’ ; 
end. 


Figure 1-8. Sample Filecopy.cmd File 
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Once the command file is set up, run the filecopy 
utility to copy all necessary information to the VAX. 
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Component Creation 


This section discusses: 


Creating a library 

Creating a new component drawing 
Creating the body shape 

Drawing pins 

Adding pin names 

Annotating pins 

Attaching properties to the body 
Building other body versions 


Borrowing library parts 


Component Creation 


Basic Procedure __| Creating a body involves the following steps: 
(Checklist) 1 Create a new library. 


2 Create the new component drawing. 
3 Create the body shape. 

4 Add pins to the body. 

5 Attach pin names to the pins. 


6 Annotate the pins (using the GED note 
command). 


7 Attach properties to the body. 


8 Build other body versions. 
Each of these steps is detailed in this section. 


Throughout these procedures, there are creation 
standards included for your information. These are 
the standards used to create all of the Valid librar- 
ies; they are the suggested standards for creating 
your own libraries. 
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Creating A 
Library 
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The first step in developing a new library is to create 
a directory for the new library where you can store - 
any parts you create. Since any change made to a 
Valid library is overwritten when that library is up- 
dated, you should also create a library of your own 
if you must modify an existing library part. Keeping 
new parts in a special library means your Valid li- 
braries can be updated without losing data. 


To create a new library on a UNIX or ULTRIX sys- 
tem, log in as user lib. By default the librarian’s 
working directory is /u0/lib on the SCALDsystem and 
PC AT or /usr/valid/lib on the DECstation and Sun 
workstation. 


To prevent access to new components until they are 
ready for distribution, create a permanent test direc- 
tory under the Jib directory. Use this directory to 
and test all new components. Do not enter the test 
directory name in the master library file. When the 
components are complete, copy the component di- 
rectory tree, place the component in the correct li- 
brary, and enter the new library name in the master 
library file. 


To create new libraries on a VMS system, log in un- 
der your own user name. A library can be cre- 
ated under any user account and later moved to the 
SCALD$ROOT: [LIBRARIES] directory (although the file 
permissions and ownership will have to be changed 
to user lib). 


Component Creation 
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Throughout this manual, a UNIX library named 
newparts (which is located under user lib) is used as 
a sample library. 


Follow these steps to create the newparts library: 
1 Log in as user lib. 


2 From the /usr/valid/lib directory, create the new 
library subdirectory: 


mkdir newparts 


3 Copy the default GED files (*.cmd and 
startup.ged) from a user directory into the new 
directory. 


4 Move to the new directory: 


cd newparts 


5 Edit the startup.ged file: 


vi startup.ged 


6 Change the “use” line to read: 


use newparts.wrk 


7 Delete the “masterlibrary” line. 
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8 Add a library command line for each existing 
library you might need to create the new 
library: 


library lsttl 
library ttl 


9 Save the startup.ged file and exit the text 
editor. 


10 Use the text editor to change the name of your 
SCALD directory in the .cmd files to the new 
directory name: 


directory ‘“newparts.wrk’; 
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Creating a New 
Component 
Drawing © 


Editing the .BODY 
Drawing 
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Because the TTL 293 binary counter component is 
not included in the Valid library release, it is used as 
an example throughout this manual to demonstrate 
the process of adding a new component to your 
library. 


To create a new component drawing, you must: 
e Edit the .BODY drawing 
e Move the body name away from the origin 


To create a new component called 293, use GED to 
edit a new drawing called 293.body.2.1. Make sure 
you add the .body.2.] extension; if you do not, the 
default drawing type is .logic and the default version 
and page number reference is ./.1. 


Version 2 of a body is the “flat” version; that is, it 
has all pins explicitly marked. Version 1 of a body 
is vectored, with multiple-bit input and output pins. 
By building Version 2 first, you can more easily see 
the relationship between the component logic and 
the body representation. 


When you edit 293.body.2.1, the screen shows a 
body grid setting, the body name, and a small X 
(the body origin) in the center of the screen. 
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Valid Graphics:Editor-(GED) 9.4 ; : : eae page oY peas wold ae a 
233, 


Figure 2-1. Editing The TTL Body 


When you edit a .BODY drawing, the grid is set 
automatically to 0.05 2. This means there is 
one-tenth of an inch (0.1 inch) between dis- 
played grid lines. Always use this grid setting 
when creating the body shape. 


i Notes and connections to slanted lines (such as 
occur on select inputs of multiplexers, for ex- 
ample) can be placed on a grid of 0.01 10 if 
necessary. Do not use any other grid settings 
when creating bodies. 
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Moving the Body 
Name 


a Origin 
Standards 


Shortening a Body 
Name 


If you change the size of 
the note, it should still 
conforms to the suggested 
Valid standards. 


2-8 


The body name, 293, is a note that you can use to 
label the component body. Be sure to include the 
component name on the body. The split command 
lets you move the body name note away from the 
body origin (the small X that appears at 0,0). 


To separate the body name and the body origin: 


1 Select the split command from the GED menu. 


2 Use the right mouse button to select the object 
to move. 


Do not move the body origin; if you do, the 
editor produces an error message when the 
body is written and moves the origin back to 
the center. If your first button click makes the 
origin move, just click again to select the body 
name. 


3 Move the note to the top of the screen and 
place it down. 


The origin body is used to specify the origin of 
the body. All body properties are attached to 
the origin body, and the body should be sym- 
metrical about the origin (the origin should be 
at the center of the body). 


In some cases, you may have a body name that does 
not easily “fit” into the shape of the body. If you 
wish to shorten the body name on a drawing, you 
can use the GED command change to shorten the 
body name note or the display command to change 
the size of the body name note to fit within the body 
shape. 
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Creating the 
Body Shape 


Note that the TTL 293 
is not centered horizon- 
tally around the origin 
but that the body falls 
directly on the major 
grid intervals. 


10/1/89 


Using GED, you can make a body any size and shape 
you want: round, oval, trapezoidal, rectangular. 
For consistency, the body shape should match the 
body function. Follow the component representation 
in the appropriate data book or use another Valid 
library component to model the shape of the body. 
In order for a body to integrate well with existing 
libraries, it should be approximately the same size 
as other library parts. When bodies are made a 
standard size and labeled in a consistent manner, 
schematics are easier to draw and maintain. 


To create the shape of the TTL 293 body, use the 
wire command to draw a rectangle 10 squares long 
by 5 squares wide. Center the rectangle around the 
body origin as much as possible while still keeping 
the body shap on-grid. The basic shape of the 
TTL 293 component is shown in Figure 2-2. 
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Figure 2-2. The TTL 293 Body Shape 


The shape of the body should reflect (wherever 
Standards possible) the function of the body. 


w The size and shape of the body depend on the 
number of input and output pins required on 
the body drawing. 


w The body should be symmetrical about the 
body origin. 


Bodies should be made as small as possible but 
not crowded. Follow the sizes of existing bod- 
ies in other libraries. Make flip-flops 0.4 by 
0.8 inches. Make gates 0.3 by 0.6 inches. 
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Drawing Pins The following pin conventions are used in all Valid- 
supplied libraries: 


e High-asserted pins are shown with a wire stub. 


@ Low-asserted pins are shown with a circle. 


Follow these steps to add pins to the TTL 293 body: 


The circle has a 1 
0.l-inch diameter. 


You can also use the 2 


copy command to create 
multiple wire stubs. 
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Use the circle command to add two low- 
asserted clock pins to the left side of the body. 
Place the first point of the circle halfway be- 
tween the first grid interval and the body edge. 
Place the second point of the circle on the body 
edge. 


Use the wire command to add four high- 
asserted pins to the right side of the body. 
Start each wire at the body edge and extend it 
one grid interval out from the body. 


Use the are and wire commands to draw an 
AND gate at the bottom of the body. Place the 
first arc point one grid interval below the body 
and halfway between the second and third ver- 
tical grid intersections. Place the second arc 
point along the same horizontal grid interval 
and halfway between the third and fourth grid 
intersections. Place the third grid point at the 
bottom edge of the body halfway between the 
first and second grid intersections. Use the 
wire command to complete the gate and to add 
wire stubs to the bottom of the gate. 
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Dots can be open or filled. 4 Use the dot command to add a dot at the end 
Use set dots_open or ; : : 

set dots filled to change of each ok ane wire stub. ahs dot tells 
the default. GED that this is a pin and that wires can be 


attached to it and connections made. The dot 
does not show up on the body when you add 
the component to a logic drawing in GED. 


The pass-through clock Remember to add the connection dots to the 


pins are along the right pass-through clock and clear pins. 
side of the body. The 


pass-through clear pins 5 Use the wire command and diagonal wires to 


are across the top of add the clock wedges to the body. 
the body 


6 Write the drawing to save it. 


The TTL 293 body now looks like the one in 
Figure 2-3. 


Valid Gruphics Editor (GED) Yb { 
293. BODY. 2.1 GRID 8.85 2 NEWPARTS. WRK 


Figure 2-3. The TTL 293 Body and Pins 
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cory AAA! 


C. Pin 
~ Standards 


Pass-through Pins 


Pass-through clock pins 
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Place input pins on the left and output pins on 
the right. Place enable and select pins on the 
bottom. Place bidirectional pins on either side, 
usually on the right. 


Connect all pins to the body with either a 
0.1-inch stub (made with a wire), or a bubble 
(0.1-inch circle), or, if the pin is bubbleable, 
with both a pin and a bubble (see page 2-15). 


Mark edge-triggered clock pins with a clock 
wedge 0.1-inch wide and 0.1-inch long. Use 
the white (center) button to draw the diagonal 
lines. 


Add pass-through pins wherever possible, es- 
pecially on clocks, enable, and select lines. Do 
not add stubs or bubbles to pass-through pins. 


Pass-through (or feed-through or bus-through) pins 
are special “shortcut” pins placed on a body to 
make it easier to wire a group of bodies together. 
Many of the components in the Valid libraries are 
provided with pass-through pins on their clock sig- 
nals. The pass-through pin is exactly opposite the 
clock signal. It lets you easily wire the clock signals 
of several library parts together. 


Pass-through pins always appear on the .BODY 
drawing of the library part, although they are invis- 
ible when you add the body to a GED drawing. 


For example, if you want to wire the clock signals of 
two LS374 components together, the pass-through 
pins allow you to wire in a direct line between com- 
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ponents. Without the pass-through pins, the wire 
would have to jog around the first component to 
connect to the second component. Figure 2-4 
shows two LS374 components wired using the pass-— 
through clock pins and two LS374 components wired 
without using the pass-through pins. 


Wiring using 
pass-through pins 


Wiring without using 
pass-through pins 


Figure 2-4. Using Pass-through Pins 


Pass-through pins are always exactly opposite 
the visible pin to which they are logically 
connected. 


w The pin names of the visible and the invisible 
pin must be the same. Identical pin names 
allow GED to interpret a wire connected to the 
pass-through pin as also being connected to 
the clock input pin. 
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Bubbled Pins 


—) 


A bubbleable pin 
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A pass-through pin never has a bubble, even if 
the pin it is associated with has a bubble. 


GED knows that pins of the same name are the 
same pin, and if one of them is bubbled, the 
other must be. This guarantees that correct 
bubble checking is performed even for pass-— 
through connections. 


When defining a pass-through pin, make sure 
that the pin it is associated with is obvious. In 
Valid libraries, this is done strictly by its posi- 
tion on the body, not by the use of a note. 


The GED bubble command replaces the wire stub of 
a pin on a body with a bubble that represents a low- 
asserted signal. You must decide which pins can be 
bubbled. 


Since a circle indicates a low-asserted pin and a 
stub indicates a high-asserted pin, a bubbleable pin 
has both a stub and a circle. The length of the stub 
is the diameter of the circle. The connection point 
(marked by a dot) is at the far end of the stub, 
where the stub and circle meet. 


To use bubbled pins in GED, you must attach the 
BUBBLED property to the body. For more informa- 
tion on the BUBBLED property, see page 2-29. 
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Adding Pin The following conventions are used for pin names of 
parts in the Valid-supplied libraries: 
Names 


e All pin names are based on the names in the 
relevant data books. 


e On parts having multiple sections, the pin 
names carry a numerical suffix to distinguish 
among the sections (the bit subscript). 


e Low-asserted pin names end with an asterisk 


* 
You can use the text character (*). 


fceeetian Hale ey Use the signame command to add pin names to the 


SET CENTER) to align TTL 293 drawing. Add the names as shown in 
the pin numbers. Figure 2-5. 
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Figure 2-5. The TTL 293 Pin Names 
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Use the show attachments command to ensure 
that all pin names are properly attached. 


‘a Pin Name The pin names on a body must correspond ex- 
actly to those on the logic, timing, and simula- 


tion drawings associated with the body. 


i Use the signame command to give the pass- 
through pin the same name as the parent pin. 


For gates, letter the input pins as found in the 
data books, or alphabetically. Letter the out- 
put pins as found in the data books, or use Y. 


The pipe character (|) is not allowed in pin 
names. This is to facilitate the syntax of the 
BUBBLE_GROUP property. 


Adding Properties There are two general properties that you can attach 
to Pin Names to pins when you enter the pin names: 

e \NAC 

e \NWC 


These properties are only used on body drawings. 
They are not required in the corresponding timing 
and simulation models or logic drawings. 
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\NAC Property \NAC stands for “no assertion check.” \NAC allows 
a signal of either assertion to be connected to a pin. 
The Compiler assigns the assertion of the first signal 
The backslash is the : a ‘ ‘ 
general propery. connected to the pin as the pin’s assertion. This 
prefix character. forces any other signals connected to that pin to 
have the same assertion as the first signal. The 
\NAC property is used when the assertion level of 
signals is not important, but all the signals must be 
compatible. 


\NWC Property \NWC stands for “no width check.” This property is 
used when the width (in bits) of a pin is not known 
or when it is desired that signals of any width may 
be connected to the pin. The Compiler determines 
the actual bit width from the context in which the 
\NWC property is used. 


Figure 2-6 shows a sample merge body that carries 
both the \NAC and \NWC properties. 


A\NWC\NAC 


Y\NWC\NAC 
B\NWC\NAC 


C\NWC\NAC 


Figure 2-6. The \NAC and \NWC Properties 
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Annotating 
Bodies 


Notes on pins are important 
since pin names do not ap- 
pear when bodies are added 
to logic drawings. 


You can use a grid setting 
of .01 10 if necessary for 
better placement. Be sure 
to set the grid spacing 
back to .05 2 after plac- 
ing notes. 
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A body should be annotated with: 
e The component name 
e The pin names 
e Any other important information 


Annotation makes the function of the body and each 
pin clear. The notes should be easily readable and 
should not be crowded. Follow these steps to anno- 
tate the TTL 293 body: 


1 Use the note command and the notes shown 
in Figure 2-7. Center the notes on the pins 
inside the body and as close to the edge of the 
body as possible. 


2 After placing the notes, make them smaller to 
minimize crowding. Use the display com- 
mand to resize the notes as follows: 
display .8: All Q pins 

The CL pin 
Pin A 
Pin B 
display .6: Bit subscripts 0, 1, 2, 3 
The words BINARY CTR 


3 Once the pins are the correct size, use the 
move command to realign the notes. 


The TTL 293 body now looks like the one in 
Figure 2-7. 
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Figure 2-7. The Annotated TTL 293 Body 


Make the body name note default size for 
Standards counters and shift registers, 0.8 for multi- 
plexers and decoders, 0.75 for smaller gates, 
and 2.0 for VLSI chips. 


Mark open collector and open emitter pins with 
OC or OE placed immediately above the bubble 
or wire stub for the pin. Display the note 0.6 
of the default size. 


Do not mark tri-state pins with a note. 


Clocks do not normally require a note; only DC 
clocks require a note. 
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Attaching A property is a name and value pair that conveys 
: information about your design to the analysis tools. 
Pr operties to the The information represented by the properties in a 


Body drawing is interpreted by the Compiler and then 
passed on to the other programs. 


The standard body properties that can be attached to 
body drawings to affect component sizing and pin 
assertion level are: 


NEEDS NO SIZE 
HAS_FIXED SIZE 
BUBBLED 


BUBBLE_GROUP 


Use the same procedure to Follow these steps to attach the NEEDS NO SIZE 


attach any body properties 
to the body origin. 


1 
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property to the origin of the TTL 293 component: 


Select the property command from the GED 
menu. 


Use the yellow button to select the body origin. 


Type the name and value of the property: 
NEEDS NO SIZE=TRUE 


The word TRUE appears on the screen. 


Use the yellow button to place the property 
value one-half grid interval above the body 
origin. 
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5 Type display invisible and point to the word 
TRUE. The property name and property value 
disappear. 


Figure 2-8 shows the TTL 293 component with the 
NEEDS_NO SIZE property attached and visible. 


Yalid Graphics Editor:(GED) 9.8 


233. BODY. 2. 1 GRID 8@.e@5 2 NEWPARTS. WRK 
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PROPERTY 


I 


Figure 2-8. The TTL 293 Body with NEEDS _NO_SIZE Property 


Once you have added the NEEDS_NO_SIZE property 
to the TTL 293 component, the basic drawing of Ver- 
sion 2 is complete. For information on building 
other body versions, see page 2-32. 
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NEEDS NO SIZE The NEEDS _NO_ SIZE property is attached to all ver- 
Property sions of a component when there are no sizeable 
versions of the component. 


e Version 1 of the body supports multiple—bit 
pins having a fixed number of bits (for exam- 
ple, PIN_NAME=Q <2..0>). 


e Version 2 of the body shows each pin 


explicitly. 
For more information Multiple—bit pins that support a fixed number of bits 
on sizeable components (vectored pins) are not affected by the SIZE property 


and the SIZE property, 


attached to the body when it is added to a logic 
see page 2-34. 


drawing; therefore, the component “needs no SIZE.” 
Attaching the SIZE property to a NEEDS _NO SIZE 
component produces a Compiler error. 


Figure 2-9 shows two versions of the LS138 compo- 
nent. Both versions have the NEEDS_NO_SIZE prop- 
erty attached; neither version is sizeable. Version 1 
has a vectored input pin with a fixed number of bits; 
Version 2 has explicit input pins. 


LS138.BODY.1.1 LS138.BODY.2.1 


cry ja 
SoD 
t D 


EN10 ee EN2Bx 
EN2Ax 


Figure 2-9. NEEDS _NO_SIZE Property 
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HAS_FIXED_SIZE 
Property 
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The other body property that affects component size 
is the HAS FIXED SIZE property. This property is 
attached to the non-vectored (explicit) version of a 
component when one version of the component is 
sizeable. HAS _FIXED_SIZE passes size information 
through to the simulation primitives. 


e Version 1 of the component supports multiple- 
bit pins that include the SIZE parameter (for 
example, PIN_NAME=Q <SIZE-1..0>). 


SIZE specifies the number of multiple bits the 
pin represents. The value of SIZE-1 depends 
on the SIZE property attached to the body when 
it is added to a logic drawing. No SIZE prop- 
erty is attached to the body drawing during 
creation, only when the body is used in a 
schematic. 


e Version 2 of the body shows each pin explic- 
itly. This is the version that carries the 
HAS _FIXED_SIZE property. 


During body creation, you attach a value to the 
HAS FIXED SIZE property to define the final 
size of the component; therefore, the compo- 
nent “has a fixed SIZE.” Attaching the SIZE 
property to a HAS FIXED SIZE component 
produces a Compiler error. 


Figure 2-10 shows two versions of the LS367 compo- 
nent. Version 1 is sizeable. There is no size 
associated with the body drawing itself; the SIZE 
property is attached to the body when it is added to 
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a logic drawing. Version 2 has a fixed size of four 
bits (4B). Version 1 has vectored input and output 
pins; Version 2 has explicit input and output pins. 


LS367.BODY.1.1 


OE 
A SIZE. .G4250 Y <SIZE-1..@> 


OE* 


LS367.BODY.2.1 


» Y €3> 
FIXES) SIZE=4B 


Y <1> 
Y <@> 


Figure 2-10. HAS_FIXED_SIZE Property 


Invisible Properties Some properties such aS NEEDS_NO SIZE and 
HAS_FIXED_SIZE are required properties that should 
not be changed by the user. These required proper- 
ties, therefore, do not need to appear on your body 
drawing. You can make these properties invisible. 


Position any invisible property 0.05 inches from the 
origin so that it may be easily located and not share 
the same coordinates as a visible body property. 
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SS 


Ce Property 
. Standards 


BUBBLE_GROUP 
Property 


Use the procedure on 
page 2-21 to add the 
BUBBLE_GROUP prop- 
erty to a body drawing. 
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All body properties are attached to the body 
origin. 


vw The only invisible properties on a body should 
be section identifiers on asymmetrical bodies 
and the NEEDS_NO_SIZE and HAS FIXED SIZE 
properties. All other properties should be 
visible. 


An invisible property must not be in the same 
location as a visible object. 


When invisible properties are attached, locate 
them 0.05 inches from the origin. 


Some library parts have pins that are logically re- 
lated to each other, so that if you bubble one of 
these pins, you must also, by definition, bubble the 
other pin. An LS367 component permits the A input 
pin and the Y output pin to be bubbled. In fact, if 
one of these pins is bubbled, the other pin must also 
be bubbled. To prevent wiring errors, pins can be 
assigned to bubble groups so that when one pin is 
bubbled, other pins are also bubbled. For example, 
if pins A, B, and C are in one bubble group, when 
any one of these pins is bubbled, they are all bub- 
bled. The BUBBLE_GROUP property is used on the 
body drawing to indicate which pins must bubble 
simultaneously. 


The BUBBLE_GROUP property is attached to the ori- 
gin of the body. Each BUBBLE_GROUP property de- 
fines one bubble group. 
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BUBBLE_GROUP [group_name]=( pin|pin[|pin|pin ] ...) 


SYNTAX : 


The group_name is an optional uppercase or lower- 
case single letter name. The group_name is not nor- 
mally used; it is not necessary to name bubble 
groups except to define a bubble group that does not 
fit on a single line in the editor. (The limit is 80 
characters.) All BUBBLE_GROUP properties of the 
same name define one large bubble group. 


pin is the name of a pin to include in the bubble 
group. You can abbreviate pin names, but make 
sure you include enough of the pin name to make 
the name unique. For example, the minimum ab- 
breviation for the pin names A<2>, A<1>, and A<0> 
is A<2, A<1, and A<0. Only the closing angle 
bracket can be _ omitted. The pin names 
Q <SIZE-1..0> and Q <SIZE-1..0>* must be typed ex- 
plicitly since only the last characters of the pin 
names differ. 


BUBBLE_GROUP=(¢AiY> 


BUBBLE_GROUP=¢(A <1iY <1) 
BUBBLE_GROUP=(I@'Y <SIZE-1..@>:Y <SIZE-1..@>*> 


Figure 2-11 shows several BUBBLE_GROUP entries 
attached to the origin of the LS367 component. (The 
TTL 293 component does not require any bubble 


groups.) 
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Figure 2-11. BUBBLE_GROUP Property 


Asymmetrical Bubble A small number of bodies (such as XOR gates and 

Groups parity generators) require an irregular arrangement 
of bubbled pins in a group. Asymmetrical bubble 
groups allow you to bubble some pins in the group 
while excluding other pins in the group. For exam- 
ple, if pins A and B are members of an asymmetri- 
cal bubble group, then bubbling pin A bubbles pin 
B, but bubbling pin B has no effect on pin A. 


If an XOR gate has inputs A and B and output Y, the 
bubble behavior should be as follows: 


If a bubble is added for: There should be a bubble for: 


A Y 
B Y 
4 A (but not B) 
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There is no way to express this using conventional 
bubble groups, but it can be expressed as follows: 


(A°Y) 
(B°Y) 
(Y"A) 


An asymmetrical bubble group has the syntax: 


| SYNTAX | BUBBLE_GROUP=(pin1“pin2\|pin3|...) 


This means that if pin] is bubbled, all the other pins 
are bubbled, but if any of the other pins are bub- 
bled, there is no effect on pinl. 


Figure 2-12 shows asymmetrical BUBBLE_GROUP 
entries attached to the origin of the LS86 component. 


BUBBLE_GROUP=¢A“Y > 
BUBBLES —GROUP=<¢ B“Y > 
BUBBLE =GROUP=c¢Y“A> 


A <SIZEI=WrA ey 
o> Y <SIZE-1..@> 
B <SIZE-1..@ al 


Figure 2-12. Asymmetrical Bubble Groups 


BUBBLED Property Once the bubble groups for a body are defined, the 
next step is to tell which pins start in the bubbled 
state and which start in the non-bubbled state. The 
BUBBLED property, also attached to the origin of the 
body, contains this information. 


BUBBLED=(pin[|pin|pin]...) 


pin refers to the pins that are bubbled by default. 
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BUBBLED=<Y> 
eee GROUP= CY: AD 


When you. attach the BUBBLED property to a pin and 
add the component to a logic drawing in GED, the 
pin appears in the bubbled state, and the circle is 
displayed. If you enter the bubble command in GED 
and point to the bubbled pin, the pin toggles to the 
non-bubbled state and the line is displayed. 


Figure 2-13 shows the LS04 component with both 
the BUBBLE_GROUP and the BUBBLED property at- 
tached to the body origin. 


EDS Y <SIZE-1..@>x 


Figure 2-13. The BUBBLED Property 


When you add the LS04 component to a logic draw- 
ing, the Y output pin is bubbled; the A input pin is 
not bubbled. When you enter the bubble command 
in GED and point to either pin, pin A is bubbled and 
pin Y is unbubbled. 


add !s04.body bubble 
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Figure 2-14. The Bubbled Pins in GED 
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Completing the Once all the required properties are attached to the 


body drawing, follow these steps to complete the 
Body Drawing drawing: 
1 Enter the show attachments command to ver- 
ify that all property attachments are correct. 
Use the reattach command to correct any in- 
accurate attachments. 


2 Enter the write command to check and save 
the drawing. 
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Building Other 
Body Versions 


Vectored 
Components 
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Once you, complete the explicit version of a compo- 
nent, you can build other body versions of the same 
component. The most common variations are a vec- 
tored version and a sizeable version. 


A vectored component has multiple—bit pins with a 
fixed number of bits. A sizeable component allows 
you to specify (with the SIZE property) the number 
of bits the part can represent when you add the com- 
ponent to a logic drawing. 


Pins on a vectored component can have vectored or 
scalar pin names. Vectored components are not af- 
fected by the SIZE property attached to the body 
when it is added to a logic drawing. A vectored 
component has the NEEDS _NO SIZE property at- 
tached to the body origin. 


Follow these steps to create a vectored version of 
the TTL 293 component. For more information on 
any step, refer to the page listed with each step. 


1 Edit a new drawing called 293.body. You do 
not need to specify the version and page num- 
ber; the default is for the system to add ver- 
sion 1 and page 1 (293.body.1.1). 


2 Use the circle, wire, arc, and dot commands 
to draw the body shape, the pins, the AND 
logic, the clock wedges, and the connection 
dots. Draw only one output pin instead of add- 
ing four individual output pins as you did on 
the Version 2 body. (Page 2-9) 
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Remember to add the connection dots to the 
pass-through clock and clear pins. 


3 Use the signame command to add the pin 
names to the body. Use the pin name Q <3..0> 
for the single output pin. (Page 2-16) 


4 Use the note command to annotate the body 
drawing. Use the display command to resize 
the notes and the move command to realign 
them if necessary. (Page 2-19) 


5 Attach the NEEDS_NO_SIZE property to the 
body origin. (Page 2-21) 


6 Write the drawing to save it. 


Figure 2-15 shows a vectored version of the TTL 293 
component. The specific differences between Ver- 
sion 1 and Version 2 are: 


e Version 2 is 10 grid units high by 5 grid units 
wide. Version 1 is 8 units high by 5 units 
wide. 


e Version 2 has four output pins with explicit pin 
names. Version 1 has one output pin with a 
vectored pin name that supports a fixed num- 
ber of bits. 


10/1/89 2-33 


Component Creation 


Valid Graphics Editor (GED) 9.9 


233. BODY. 1.1 


Sizeable 
Components 
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Figure 2-15. Version 1 of the TTL 293 Body 
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When you add a new part to a library, you must 
decide if it can be made into a sizeable part. If it is 
possible to make a part sizeable, you must then de- 
cide which control signals should be driven in paral- 
lel and which should be provided on a per-bit basis. 
At least one pin of a sizeable component must be a 
sizeable pin (SIZE-1..0); all other pins can be size- 
able, vectored, or scalar pins. 


Consider creating a D flip-flop that has a preset and 
clear for each section. Should these inputs be 
sizeable (meaning that each bit can be cleared and 
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set individually), or should these be single—bit sig- 
nals that set and clear all the flip-flops simultane- 
ously? The answer depends on how you expect the 
part to be used. The decision does not rule out any 
particular design, but it does make some designs 
easier to enter than others. 


If you make the preset and clear sizeable, then a 
user who wishes to clear the entire register must ex- 
tend the clear signal to the correct size to prevent a 
width mismatch. Since most sizeable flip-flops are 
used as registers, this is a good argument for mak- 
ing preset and clear single-bit signals. 


On the other hand, if the signals are made single-bit 
and the user really needs a register where each bit 
can be asynchronously cleared and preset independ- 
ently, you must draw the register with one body per 
bit. This is equivalent to the non—-vectored design 
style for this particular register. 


Not all parts can be made sizeable. In an ALU, for 
example, CARRY IN and CARRY OUT are connected 
neither in parallel nor on a per-bit basis. Therefore, 
an ALU is not a sizable part. Gates, on the other 
hand, require no control signals and can always be 
made sizeable. 
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Pin Names for Sizeable 
Components 


See the SCALD Language 
Reference Manual for 
more information on Sig- 
nal syntax in the different 
library formats. 
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When you build a sizeable library component, the 
pins (or some of the pins) of the component must 
also be defined as sizeable. Parts may be made to 
handle an arbitrary number of bits by providing mul- 
tiple-bit pins and vectored pin names with the 
SIZE-1 parameter. The width of the data path is 
then determined by the SIZE property placed on the 
component when it is added to a logic drawing. 


For the standard Valid library format (format 1), a 
sizeable pin name is specified as: 


PIN_NAME=name <SIZE-1..0> 


The variable name is the name of the sizeable pin. 
The parameter SIZE-1 specifies the number of mul- 
tiple bits the pin is to represent. The value of 
SIZE-1 depends on the value assigned to the SIZE 
property attached to the body when it is added to a 
logic drawing. 


For example, if you attach the property SIZE=4B to a 
sizeable component (in a logic drawing) with a 
Y<SIZE-1..0> Output pin, the resulting value is 
Y <3..0>. Attaching the property SIZE=2B results in 
the value Y <1..0>. 


10/1/89 


Component Creation 


The top half of Figure 2-16 shows the sizeable body 
version (Version 1) of the LS78 component. The 
bottom half shows the component when you add it 
to a logic drawing and attach the SIZE property. 


J <SIZE-1. .@> 


CLOCK>k D CLOCKx* 


K <SIZE-1.. » Q <SIZE-1.. 


Figure 2-16. LS78 Sizeable Component 
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Modifying 
Existing 
Components 


The Smash 
Command 
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For some components you want to create, you may 
be able to copy an existing library component and 
alter the component for your use. For example, the 
TTL 293 component looks exactly like the LSTTL 
LS293 component; the differences are in the electri- 
cal characteristics. You can use GED to make a 
copy of the LSTTL component and modify it for use 
as a TTL component. 


There are two methods of copying library 
components: 


e Use the smash command on an added body 
drawing. 


e Use the diagram command to change the 
name of a borrowed drawing. 


Both of these are alternate methods of creating the 
TTL 293 component you already created in this 
section. 


Follow these steps to create Version 2 of the TTL 293 
body by copying the LS293 component. 


1 Edit a new drawing called 293.body.2.1. 


2 Add Version 2 of the LS293 component to the 
new drawing: 


add 18293. .2 


Center the LS293 body around the origin of the 
new drawing. 
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Enter the smash command and point to the 
LS293 component. This command separates 
the body into individual wires, arcs, and cir- 
cles. Any properties attached to the LS293 
component are deleted. 


Use the delete command to remove the incor- 
rect body name (LS293). 


Use the split command to move the new body 
name away from the body origin. Place the 
new body name at the top of the body and dis- 
play it to the correct size. 


Use the dot command to place connection 
points on each pin. 


Use the signame command to add the pin 
names to the body. 


Use the property command to attach the re- 
quired properties to the body origin. 


Write the drawing to save it. 
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The Diagram Follow these steps to use the diagram command to 
Command create Version 2 of the TTL 293 drawing. 


1 Edit Version 2 of the LS293 drawing: 
edit 18298.body.2.1 
2 Use the diagram command to rename the 
drawing: 
diagram 293.body.2.1 


The system brings up the same drawing under 
the new drawing name. All properties are at- 
tached exactly as they were under the original 
drawing name. 


3 Enter the command: 
ignore Ilsttl 


This command removes the reference to the 
Isttl library so you can write the drawing into 
your own .wrk file. 


4 Use the write command to save the drawing 
under the new drawing name. 


5 Enter the command 
library lsttl 


to reference the Isttl library again. 


6 Use the change and move commands to edit 
the body name and center it within the body. 


¢ Write the drawing to save it. 
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Completing a To complete a new component, you must: 


Component e Create the physical model for the Packager 
| (add pin numbers, output type, etc.) 


e Create a simulation model (if necessary) 
e Create a timing model (if necessary) 
e Test the component 


If you use the smash or diagram method and mod- 
ify an existing component to create a new compo- 
nent, you also need to make the necessary changes 
to the .PART, .SIM, and .TIME drawings for the body 
to complete the new component. 
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This section discusses: 


e Creating a .PART drawing 

e Modifying an existing .PART drawing 
e Creating a library drawing 

e Adding body properties 

e Adding pin properties 

e Adding a drawing body 

e Completing a library drawing 

e Modifying an existing library drawing 
e Editing the compiler.cmd file 

e Compiling a library drawing 


® Creating individual chips files 


Physical Model 


Creating the 
PART Drawing 


The DRAWING body cannot 
be added to a .BODY drawing 
since it would appear with the 
body on the schematic. 


Compiling a component 
without a .PART draw- 
ing produces the error 
message “no useable 
extension found.” 
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The .PART drawing tells the Compiler that the com- 


ponent is a primitive, or lowest-level, body. It is not 
a hierarchical body; there is no logic below the body 
or inside it. There is only one item included in a 
-PART drawing: the DRAWING body. 


The DRAWING body specifies properties of the entire 
component. You attach the TITLE property (which 
is the logical part name) and the ABBREV property 
(which is an optional abbreviation for the compo- 
nent name to be used when constructing path ele- 
ments). If the physical part name is different than 
the body name, you must also attach the 
PART_NAME property. For example, the logical part 
name LS00 corresponds to the physical part name 
74LS00. 

Follow these steps to create a .PART drawing for the 
TTL 293 component: 


1 Access GED and edit a file named 293.part. 
2 Add a DRAWING body to the file: 
add drawing 


3 Select the property command from the menu 
and point to the DRAWING body. 


4 Add the TITLE, ABBREV, and PART_NAME 
properties below the word DRAWING: 


title 293 
abbrev 298 
part_name 74293 
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5 Enter the command 
display both 


and point to each property. 


6 write the drawing to save it. LAST_MODIFIED 
now reflects the current date and time. 


The .PART drawing for the TTL 293 component is 
shown in Figure 3-1. 


ValidsGraphi esgEditor: (GED)S95O rset A os ERR Br ee ae 


per ce we aa 


293. PART. 1.1 GRID 8.1 5 NEHPARTS. HRK HELP 


(Gav) 
((exston_) 
((enour__} 
(corr__} 

_DRAWING | DELETE 
TITLE=293 Ge) 
ABBREV=293 (Ge) 


PART_NAME=742393 
LAST_MODIFIED=Wed Aug 2 14:21:19 1989 Ga) 


a 


PROPERTY 


ROUTE 
TRECTORY. 


10/1/89 . 3-3 


Physical Model 


Modifying an If you copy an existing component and modify it to 

ate create a new component, you should also copy the 
Existing -PART existing .PART drawing and modify the DRAWING 
Drawing body to match the new drawing name, abbreviation, 


and part name. 
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Creating the Creating a physical model by adding physical infor- 
: mation to a library component requires the following 
Physical Model: | gteps. 


Basic Procedure ae seeds cian seis 
- reate a library drawing and a the sizeable 
(Checklist) : 


or vectored version of the body. 
2 Attach the body properties. 
3 Attach the pin properties. 


4 Verify property attachments, check and write 
the drawing. 


5 Edit the compiler.cmd file. 
6 Compile the library drawing. 


7 Move the chips.dat file to the individual com- 
ponent directory and rename it chips_ prt. 


Each of these steps is detailed in this section. 
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Creating the 
Library Drawing 


See Archiving Library 
Drawings, page 3-31, 
for more information 
on archival. 


Refer to Appendix B for 
changes between the 
previous library drawing 
method and the current 
library drawing. 


Standards 


The library drawing is used to transfer physical infor- 
mation from GED to the Packager. This drawing 
shows the sizeable version of a component to be 
packaged (usually Version 1). 


The name of the library drawing should reflect the 
component you are modeling. You can keep or dis- 
card the library drawing for a component depending 
on your choice of archival methods. 


Follow these steps to create a library drawing for the 
TTL 293 component: 


1 Access GED and edit the library drawing: 


edit newparts library 


2 Add the sizeable version (Version 1) of the 
component to be compiled: 


add 293.body 


~ Parts having asymmetrical sections should 
have one of each of the sections added to the 
drawing. 


~ Asymmetrical sections cannot have any 
common pin names. 
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Adding Body 
Properties 


On the UNIX operating 
system, there is a text file 
method of adding physical 
information. Refer to 
Appendix A for details. 


10/1/89 


Several body properties are attached to the origin of 
a component on the library drawing. These proper- 
ties pass information about the component to the 
Compiler or other Valid analysis tools: 


e FAMILY 

e POWER PINS 

e BODY TYPE 

e COST 

e PART NUMBER 

e PHYS DES PREFIX 


Follow these steps to add the FAMILY and 
POWER_PINS properties to the TTL 293 component in 
the NEWPARTS LIBRARY drawing: 


1 Select the property command from the GED 
menu. 


2 Enter the FAMILY property for the 293 
component: 


FAMILY = TTL 


3 Enter the POWER_PINS property: 


POWER_PINS=(VCC:14; GND: 7) 
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The TTL 293 component and body properties appear 
in Figure 3-2. 


Valid Graphics’ Editor (GED) 9.0: 


sae ~ or t ; 
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Figure 3-2. The TTL 293 Body Properties 


FAMILY Property The FAMILY property specifies the logic family of a 
component. The property can have any value. 
Some of the values used in the Valid libraries are: 


FAMILY = TTL 
FAMILY = LSTTL 
FAMILY = ECL100K 


Attach the FAMILY property to the body origin. 
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POWER_PINS 


Property 


pin list 
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The POWER_PINS property specifies the power and 
ground pin assignments for each component. The 
property specifies both the power supply (power 
rail) names and the pin numbers of pins connected 
to the supply. 


POWER_PINS=(supply:pin list; supply;pin list; ...) 


The power supply name. The name must be an al- 
phanumeric identifier starting with a letter (for ex- 
ample, vcc). The supply name may include an 
underscore (_ ). 


A list of the pin numbers of the part that connect to 
the supply. The pin numbers are separated with 
commas. 


A colon is used to separate the supply name and the 
pin list. A semicolon is used to separate each sup- 
ply specification. 


The TMS4050 RAM has the POWER_PINS property: 
POWER_PINS=(VBB:1; VDD:10; VSS:18) 

The 100123 bus driver has the property: 
POWER_PINS=(VCC:6; VCCA:7,9,11,5,3,1; VEE:18) 


The order of the pin assignments is not important. 
The POWER_PINS property only applies to library 
parts and is ignored if attached to a body that is not 
a library part. Attach the POWER_PINS property to 
the body origin in the library drawing. 


3-9 


Physical Mode! 


BODY_TYPE Property 


You can also use the prop- 
erty COMMENT_BODY=TRUE 
to comment out a body. 


COST Property 


PART_NUMBER 
Property 


PHYS DES PREFIX 
Property 
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The BODY_TYPE property is used to “comment out” 
bodies that have no logical function. For example, a 
company logo requires a BODY_TYPE property be- 
cause the logo has no logical meaning. The 
BODY_TYPE property has the following syntax: 


BODY_TYPE=COMMENT 


The COST property specifies the cost of a component 
at your site. This property is not used in the Valid 
libraries since it contains site-specific information. 
Since this property is not a constant value, it might 
be handled more easily using physical part tables. 
See the ValidPACKAGER Reference Manual for infor- 


mation on physical part tables. 


The PART_NUMBER property is used to assign an in- 
ternal part number for the component. This prop- 
erty is not used in the Valid libraries. 


The PHYS_DES PREFIX property allows you to 
change the prefix of the physical descriptor to match 
your requirements. For example, you can use physi- 
cal reference designator of “Ic” for an integrated 
circuit rather than the default “u.” 
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Physical Model 


Adding 
Pin_Number 
Properties 
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Each pin (except pass-through pins) of every library 
component (and all versions of a component) must 
have a PIN.NUMBER property attached. The 
PIN_NUMBER property tells the Packager: 


e The pin number for the pin 


e The number of sections of the component in a 
package 
e The pin numbers for each section 
There must be one pin number on each pin for each 
section. For example, if a package has four sec- 
tions, there must be four pin numbers on each pin. 
The Packager prints an error message when a pin is 


found without a PIN_.NUMBER property or without 
the correct number of pins per section. 


Follow these steps to add the PIN_NUMBER property 
to the TTL 293 component in the NEWPARTS 
LIBRARY drawing: 


1 Choose the property command from the GED 
menu and select the CLKA pin. 


2 Enter the PIN.NUMBER property for the CLKA 
pin: 
PIN NUMBER=(10) 


Locate the property to the left of the CLKA pin. 


3 Select the CLKB pin and type the PIN.NUMBER 
property for the pin: 


PIN _NUMBER=(11) 


Physical Model 


The pin number sequence 
follows the pin name Sse- 
quence (Q<3..0>). 
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Locate the property above the CLKA pin 
number. 


Select the CLi pin and type the PIN.NUMBER 
property for the pin: 


PIN _NUMBER=(12) 


Locate the property near the CLi pin. 


Select the CL2 pin and type the PIN.NUMBER 
property for the pin: 


PIN _NUMBER=(13) 
Locate the property near the CL2 pin. 


Select the vectored Q pin and type the vectored 


-PIN_NUMBER property for the pin: 


PIN _NUMBER=(<9,5,4,8>) 


Locate the property near the Q pin. 


The pin number properties for the TTL 293 compo- 
nent are shown in Figure 3-3. 
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Figure 3-3. The TTL 293 Component with Pin Numbers 


Pin Number Formats | There are different pin number formats available de- 


pending on the type of library part you are develop- 
ing. The formats define the following types of pin 
assignments: 


e Single section scalar pin 

e@ Single section vector pin 

e Multiple section scalar pin 

e Multiple section common pin 

e Multiple section common vector pin 
e Asymmetrical components 
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Single Section Scalar 
Pins 


The clock and clear pins of 
the TTL 293 component 
are also examples of single 
section scalar pins. 


Single Section Vector 
Pins 


A scalar pin is a pin that corresponds to a single-bit 
signal. A vector pin corresponds to a fixed number, 
multiple-bit signal. A pin_id (the PIN_NUMBER 
property) consists of any alphanumeric character 
and/or the underscore character. The maximum 
length of a pin number is 16 characters. 


The PIN.NUMBER property for each pin of a simple 
one-section part has the format: 


PIN_NUMBER=(pin_ic) 


The pins of the LS30 NAND gate are examples of 
single section scalar pins. 


N_NUMBER=«6> _|%32 
N_NUMBER=¢11) 
N_NUMBER=¢ 12) 


A vector pin has a fixed number of bits. It is not 
affected by the SIZE property. Each bit of the vector 
connects to the same section of the part. The 
PIN_NUMBER format for a vector pin is similar to the 
format for a scalar pin, except that each logical pin 
number includes several physical pin numbers en- 
closed between left and right angle brackets: 


PIN_NUMBER=(< pin_id, pin_id, ... >) 


The angle brackets indicate that the pin represents 
multiple bits. The pin numbers in the list are sepa- 
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rated by commas. For example, a 4-bit pin is speci- 
fied as follows: 


The bits of a multiple-bit pin are assigned to the 
physical pin numbers specified in the PIN.NUMBER 
property in the following manner: 


1 The bit having the lowest subscript is assigned 
to the first pin number in the list. 


2 The bit with the next lowest subscript is as- 
signed to the second pin in the list, and so on. 


The least significant bit is assigned first because 
there must always be at least one bit per pin. 


PIN NUMBER=(<1,2,4,5>) 


The data buses of an LSi81 ALU are examples of 
single section vector pins. 


PIN NUMBER=¢ ¢ 19s 21, 23s 2> > 
PIN_NUMBER=¢¢13; 11s 10, 9>> 


PIN ONUMBER=¢ ¢< 16s 20) 22s 1>> 


PIN NUMBER=¢ <3; 4; Ss G> > 


The Q pin of the TTL 293 component is also an ex- 
ample of a single section vectored pin. 
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Multiple Section Scalar 
Pins 


Many physical components contain several identical 
logical components. Each logical component is con- 
sidered a section of the physical component. For 
example, the LS00 logical component is a single 
2-input NAND gate; the 74LS00 physical component 
contains four 2-input NAND gates, or four sections. 
The pins on this type of component are defined as 
sizeable pins. 


To identify the sections of a component, each pin of 
the logical component has a PIN_.NUMBER property 
that contains a list of pin numbers, one pin number 
for each section in the part. For a multiple section 
scalar pin, the PIN.NUMBER property has the follow- 
ing syntax: 


PIN NUMBER=(pin_id, pin_id, pin_id, pin id, ...) 


The pin numbers for each section are separated by 
commas. Pins for the first section are in the last 
position, pins for the second section are in the 
second-last position, and so on. 


The LS00 component is an example of a sizeable 
component with multiple section scalar pins. If the 
component is given the property SIZE=4B, each logi- 
cal pin of the component has four pin numbers, one 
for each section: 


PIN -NUMBER=¢15 45 9; 12) 
Cr) PIN -NUMBER=¢3;> 6: 8 11) 
PIN -NUMBER=Ce@s Ss 10>) 13> _jcseo 
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Multiple Section 
Common Pins 


Some multiple-section components have pins that 
are common to several sections. For example, the 
LS374 octal register has eight sections with a com- 
mon clock pin and a common output enable pin. 


The syntax for the PIN.NUMBER property is the 
same for a multiple section common pin as for a 
multiple section scalar pin: 


PIN_NUMBER=(pin_id, pin_id, pin_id, pin_id, ...) 


The pin numbers for each section are separated by 
commas. Pins for the first section are in the last 
position, pins for the second section are in the 
second-last position, and so on. Since common pins 
have the same pin number for each section, and 
each section must have a pin number entry, the 
common pins have identical PIN.NUMBER entries. 


Each logical pin of the LS374 component has eight 
pin numbers, one for each section: 


PIN NUMBER=(€3>s 45 7s Gs 13; 145 17s 18> PIN_NUMBER=¢2) S) 6: Gs Les 15» 16; 199 


PIN_NUMBER=C11» 11; 11s 11) 11511; 11; 11) 


OE 
O) 
PIN NUMBER=c¢1s1si,1:1,1+1,1) 
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The clock and enable pins are common to all eight 
flip-flops in the package. The D and Q pins are 
defined so that one bit is assigned to each flip-flop. 
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Some components with multiple-sections have pins 
that are common only to certain sections of the part. 
These are represented the same way as pins that are 
common to all sections, except that the pin numbers 
are present only in the sections for which they are 
common. For example, the LS367 hex bus driver 
component has the following pin number 
assignments: 


PIN _NUMBER=¢2s 45 6; 10; Las o> PIN_-NUMBER=¢3> Ss 7» Ss 11, 13> 


PIN -NUMBER=¢1, 1s 151; 15) 15> 


Multiple Section 
Common Vector Pins 
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The pin numbers for the open emitter pin show that 
one open emitter pin is common to four sections of 
the component (pin 1), and one open emitter pin is 
common to the other two sections of the component 
(pin 15). 


If a multiple-section component has vectored pins, 
the PIN_NUMBER property has the following syntax: 


PIN_NUMBER=(<pin_id,pin_id,...>,<pin_id,pin_id,...>, ...) 


Each pin number and section are separated by com- 
mas. The pin numbers enclosed in angle brackets 
specify individual bits of the pin, not different sec- 
tions for the pin. 


For example, a 3-bit pin in a component with two 
sections might be specified as: 


PIN_NUMBER=(<1,2,3>,<5,6,7>) 
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An LS189 16-word by 4-bit RAM is an example of a 
component having vector pins and multiple sections. 


PIN NUMBER=¢ 4, 6G, 10, 12> PIN -NUMBER=C€5» 7: Ss Lid 


PIN_NUMBER=(< 15 13» 145 15>0 <1. 13» 140 15>, ¢1s 13s 14s 15>s <1» 13) 14, 15>> 


Asymmetrical 
Components 


PIN_NUMBER=¢2:2:2:2> PIN_NUMBER=(3, 3) 3, 3> 


Some components have multiple sections that are 
functionally different. In this case, one version of 
the body is defined for each type of section in the 
part. To identify which pins are present in a given 
section, the pins of the different versions all have 
different pin names. 


Even though some pins may not be present in a sec- 
tion, the PIN_.NUMBER property values for the pins 
specify all the sections of the part. Any pin that is 
not present in a given section is specified with a pin 
number of 0. 


For example, the LS241 bus transceiver has four 
buffers with active-high enables and four buffers 
with active-low enables. The pin numbers are de- 
fined as follows: 


PIN NUMBER=¢17s 15, 13, 11, 0,0; @) O> PIN_-NUMBER=¢33; Ss 7s Ss Os A> As Bd 


PIN_NUMBER=¢ 19s 19s 19s 19> Os Os @, Od 


PIN -NUMBER=¢@> @: Qs Qs 2s 4; Gs 8D PIN NUMBER=¢@s Q; @s Os 18s 16s 14, 12> 
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PIN.NUMBER=¢2; 0@:0,@,1,1:13;13 


Physical Model 


Compact Pin 
Number Syntax 
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Rather than entering each individual pin number for 
all the pins of a body, the PIN_NUMBER property 
allows you to enter pin numbers in a more compact 
syntax. The syntax allows you to abbreviate bit sub- 
ranges and repeated sections. 


When specifying a subrange, the range values must 
be separated by two periods (..) for all library 
formats. 


The subrange compact syntax allows a list of bit sub- 
scripts to be abbreviated to include only the first and 
last subscripts. The repeat section syntax allows 
identical lists of bit subscripts to be abbreviated to 
one list and reiterated using a multiplier character. 
Combinations of these two syntaxes can be used to 
identify more complex pin numbers. 


The subrange and repeat section functions also ac- 
cept alphanumeric pin designations. The beginning 
and ending pin numbers of an alphanumeric sub- 
range must: 


e Begin with the same set of characters 
e End with different integers 


For example, PIN_NUMBER=(DA7..DA0) is legal 
while the PIN.NUMBER=(DA7..AA0) is not legal. 


Table 3-1 shows an example of each compact 
syntax. The long pin number under “combination 
syntax” is shown on two lines for documentation 
purposes only. 
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Table 3-1. Compact Pin Number Syntax 


Subrange Syntax Abbreviation 


PIN. NUMBER=(7,6,5,4,3,2, 1,0) PIN. NUMBER=(7..0) 
PIN. NUMBER=(<7,6,5,4,3,2,1,0>) PIN_ NUMBER=(<7. .0>) 


Repeat Section Syntax 


PIN. NUMBER=(7,7,7,7) 
PIN. NUMBER=(<1,2,3,4>,<1,2,3,4>) 


Pin Type 


Scalar 


Vector 


Scalar PIN_NUMBER=(7 * 4) 


PIN_NUMBER=(<1..4> * 2) 


Vector 


Combination Syntax 


Scalar PIN_NUMBER=(3,3,3,3,4,4,26) 


PIN_NUMBER=(<2,3,4,5>,<2,3,4,5>, 
<2,3,4,5>,<23,26,27,28>) 


PIN_NUMBER=(3 * 4, 4 * 2, 26) 


Vector PIN_NUMBER=(<2..5> *3, <23,26,27,28>) 
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Adding Other 
Pin Properties 


If you are attaching more 
than one pin property toa 
pin, you only need to se- 
lect the pin once. That 
pin becomes the default 
attachment point for the 
property command. 
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Besides the PIN.NUMBER property, there are several 
other standard pin properties attached to the pins of 
each component on the library drawing. These stan- 
dard pin properties are: 


e OUTPUT_LOAD e NO_LOAD_CHECK 
e INPUT _LOAD e NO 10 CHECK 
e BIDIRECTIONAL e ALLOW_CONNECT 
e PIN _GROUP e OUTPUT TYPE 


e UNKNOWN_LOADING 


Follow these steps to add the remaining pin proper- 
ties to the TTL 293 component: 


1 Select the property command from the GED 
menu and select the Q output pin. 


2 Enter the OUTPUT_LOAD property for the Q 
pin: 
OUTPUT_LOAD=(16.0,-0.8) 
Locate the property below the PIN NUMBER 


property for the Q pin. 


3 Enter the INPUT_LOAD property for the CLKA 
and CLKB pins. Although the pin properties 
are identical, attach one INPUT_LOAD property 
to each pin: 


INPUT_LOAD=(-3.2,0.08) 


Locate the property below the PIN.NUMBER 
properties for the CLKA and CLKB pins. 
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4 Enter the INPUT_LOAD properties for the CL1 
and CL2 pins. Although the pin properties are 
identical, attach one INPUT_LOAD property to 
each pin: 


INPUT_LOAD=(-1.6,0.04) 


Locate the properties below the PIN. NUMBER 
properties for the CL1 and CL2 pins. 


The loading properties for the TTL 293 component 
are shown in Figure 3-4. 


Malid GraphiessEd itor: (GED 9 8» SoM 
NEWPARTS LIBRARY. LOGIC. 1.1 GRID 0.1 S 


FAMILY=TTL 
POWER_PINS=<(UCC: 143 GND: 7> 


PIN_NUMBER=¢ ¢8s 45 Ss >.> 
OUTPUT_LOAD=<¢ 16. @s -@. B> 
PIN _NUMBER=¢ 11) Clos 
INPUT_LOAD=¢(—3. 2; 0. 05> 
No Se Gee 
INPUT_LOAD=¢—3. 2: 0. 08 


PIN_NUMBER=¢1l2> PIN -NUMBER=¢13) 


INPUT LOAD=(~-1.6:0.04) INPUT_LOAD=(~-1L. 6; 0. 04> 


Figure 3-4. The TTL 293 Pin Loading Properties 


10/1/89 3-23 


Physical Model 


&” Pin Property 
Standards 


OUTPUT_LOAD 
Property 


See the ValidPACKAGER 
Reference Manual for more 
information on loading 
properties. 


INPUT_LOAD 
Property 
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~ All pins must have either the OUTPUT_LOAD 
or INPUT_LOAD property or both properties. 


~ If the pin is an output (has the OUTPUT_LOAD 
property) and can be wire-tied to another out- 
put, it must be given the OUTPUT_TYPE 


property. 


~ If the pin is both an input and an output, the 
BIDIRECTIONAL property is required. 


The OUTPUT_LOAD property is attached to any pin 
that is an output pin. The syntax of the 
OUTPUT_LOAD property is: 


OUTPUT_LOAD=(/ow current,high current) 


OUTPUT_LOAD is typically measured in milliamps. 
If there is a different measurement used in the data 
book, convert the measurement to milliamps. 


The Q pin of the TTL 293 component carries the 
OUTPUT_LOAD property: 


OUTPUT_LOAD=(16.0,-0.8) 


If the loading on a component is not a critical factor, 
there is a variable OUTPUT_LOAD syntax: 


OUTPUT_LOAD=(*, *) 


The INPUT_LOAD property is attached to any pin 
that is an input pin. The syntax of the INPUT_LOAD 


| property is: 


INPUT_LOAD=(/ow current,high current) 
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BIDIRECTIONAL 
Property 


PIN_GROUP Property 
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INPUT_LOAD is typically measured in milliamps. If 
there is a different measurement used in the data 
book, convert the measurement to milliamps. 


The input pins of the TTL 293 component carry dif- 
ferent INPUT_LOAD properties: 


A & B inputs: INPUT_LOAD=(-38.2,0.08) 
Clear inputs: INPUT_LOAD=(-1.6,0.04) 


If the loading on a component is not a critical factor, 
there is a variable INPUT_LOAD syntax: 


INPUT_LOAD=(*, *) 


A pin with the INPUT_LOAD and OUTPUT_LOAD 
properties attached is an output pin which may also 
load the net. To make the pin bidirectional, attach 
the BIDIRECTIONAL pin property. A pin is not con- 
sidered bidirectional unless the BIDIRECTIONAL 
property is attached. The syntax of the property is: 


BIDIRECTIONAL=TRUE 


The PIN_GROUP property assigns the pins of a com- 
ponent to pinswap groups. The Packager and the 
GED command pinswap use the PIN_GROUP prop- 
erty to identify swappable pins. 


A pinswap group contains those pins that are logi- 
cally equivalent and belong to the same section. If 
two signals are swapped between two pins that are 
in a pinswap group, the logical behavior of the cir- 
cuit is not altered. The PIN_GROUP property has the 
syntax: 


PIN_GROUP=number 
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PIN—-GROUP=1 
PIN-GROUP=1 
PIN-GROUP=1 
PIN_GROUP=2 
PIN_GROUP=2 
PIN _GROUP=2 


PIN_GROUP=3 
PIN..GROUP=3 
PIN_GROUP=4 
PIN_GROUP=4 
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N—GROUP= 
—GROUP= 


Each pin in a pinswap group must have a 
PIN_GROUP property attached. All the PIN_GROUP 
properties must have the same value. The value of 
the PIN_GROUP property is not important, only that 
all pins of a pinswap group have an identical value. 
Any pin without the PIN_GROUP property cannot be 
swapped with any other pins. 


For example, the input pins of an LS30 NAND gate 
(A, B, C, D, E, F, G, and H) all belong to the same 
pinswap group. For each pin, the PIN_GROUP prop- 
erty has the property value “1.” The PIN_GROUP 
property is not attached to the output pin (y*) since 
this pin cannot be swapped with any other pin on the 
component. 


The LS51, 2-wide 3-input, 2-wide 2-input AND-OR- 
INVERT gate is an example of an asymmetrical com- 
ponent with more complex pinswap groups. There 
are four pinswap groups, one for each AND gate. 
The inputs for each AND gate are equivalent and 
therefore swappable. However, inputs from differ- 
ent AND gates are not swappable, so the PIN_GROUP 
properties have a different value. 


The output pins YO* and Y1* do not have 
PIN_GROUP properties because they cannot be 
swapped with any other pins. 
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OUTPUT TYPE 
Property 


OUTPUT_TYPE=(0C,AND) 
OUTPUT_TYPE=(OE,OR) 
OUTPUT_TYPE=(TS,TS) 
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The OUTPUT_TYPE property is added to the output 
pins of open-collector, open-emitter, and tri-state 
gates. The property serves three purposes: 


e Allows the pin to be connected to other 
outputs. 


e Specifies the type of output so that only com- 
patible outputs can be connected together. 


e Specifies the logic function created by tying the 
outputs together. 


The OUTPUT_TYPE property provides information 
that is needed by the Packager, the Timing Verifier, | 
and the Simulator. The property must appear on 
both the timing and simulation models as well as in 
the library drawing. 


Each output pin that can be connected to other out- 
put pins must have an OUTPUT_TYPE property. The 
property value specifies the pin type and also the 
logic function created by tying the outputs together. 
The form of the OUTPUT_TYPE property value is: 


OUTPUT_TYPE=(output type,logic function) 


Output type can be open collector, open emitter, or 
tri-state (TS). Logic function can be AND, OR, or 
tri-state (TS). Be sure there is no space after the 
comma in the property value. The output type and 
logic functions can be combined as follows: 

Open collector, AND logic function 

Open emitter, OR logic function 


Tri-state, tri-state logic function 
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MAX _DELAY=18800 


oc 
QUTPUT_TYPE=¢0C; AND? 


Load Checking 
Properties 


NO_LOAD_ CHECK 
Property 


NO_IO_CHECK Property 


ALLOW_CONNECT 
Property 


UNKNOWN_LOADING 
Property 
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The LS09 component shows the open collector, AND 
logic function OUTPUT_TYPE property. 


Since tri-state pins are considered both input and 
Output pins, they need both INPUT_LOAD and 
OUTPUT_LOAD properties. When a pin is in tri- 
state mode, the tri-state loading is specified as the 
INPUT_LOAD. 


The properties NO LOAD CHECK, NO_IO CHECK, 
and ALLOW_CONNECT can be attached to a single 
pin, a body, or a net (where they check all pins on 
the net). The UNKNOWN_LOADING property can be 
attached to a single pin or to a body. See the 
ValidPACKAGER Reference Manual for more informa- 
tion on the load checking properties. 


When the NO_LOAD_CHECK property is attached to a 
pin, it suppresses device loading calculations for that 
pin. You can suppress the load check for the Low 
State, the HIGH state, or BOTH high and low states. 


When NO_IO_ CHECK is attached to a pin, it sup- 
presses the input/output checking for that pin. You 
can suppress the input/output check for the Low 
State, the HIGH state, or BOTH high and low states. 


Attach the property ALLOW_CONNECT=TRUE if there 
are pins which require multiple outputs of different 
types to be connected together. 


If there are parts in a design that have pins with 
unknown or unspecified loading, use the property 
UNKNOWN_LOADING=TRUE to suppress load and 1/O 
checks on a pin. 
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Completing the 
Library Drawing 


Modifying an 
Existing Library 
Drawing 


10/1/89 


Once all the required properties are attached to the 
library drawing, follow these steps to complete the 
drawing: 


1 Enter the show attachments command to ver- 
ify all properties are present and correctly at- 
tached. Use the reattach command to correct 
any inaccurate attachments. 


2 write the drawing to save it. 


If you are copying an existing library and modifying 
components in that library, the best way to create 
the library drawing for the new library is to borrow 
the library drawing from the library where you bor- 
rowed the parts. If you are not changing the physi- 
cal information, then you don’t need to change any 
of the information on the library drawing other than 
its title and abbreviation. If you need to change 
physical information, use the GED change com- 
mand to change the values of the pin and body prop- 
erties on the library drawing. 
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Creating the 
Physical Model 
File 


Check the cmplst.dat 
file if any compilation 
errors occur. Correct 
any errors and recom- 
pile the drawing until an 
error-free run occurs. 
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When the library drawing is correct and complete, 
you must make the physical model file from the li- 
brary drawing. 


The physical model is used by the Packager and by 
the section and pinswap commands to read the 
pin numbers you attached to the component during 
the design stage. To create the physical model, you 
need to: 


e Edit the compiler.cmd file. 
e Compile the library drawing. 


e Rename and relocate the resulting data file. 


Follow these steps to create the physical model for 
the TTL 293 component: 


1 Edit the compiler.cmd file as follows: 


e Change the ROOT_DRAWING directive to 
reflect the correct drawing name. 


e Change the output type to “chips.” 


e Make sure the DIRECTORY directive 
points to the correct .wrk file. 


2 Compile the library drawing to create the 
chips.dat file. 


3 After the drawing compiles successfully, 
change the name chips.dat to chips_prt and 
move the physical model to the correct compo- 
nent subdirectory: 


mv chips.dat 293/chips_prt 
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Archiving Library 
Drawings 
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Once the physical information is complete and the 
chips_ prt file exists, the library drawing is no longer 
required. You can either archive the library drawing 
or delete it. 

You can archive library drawings by: 


e Creating a “save” directory to store all library 
drawings. 

e Using a tape archive utility (such as tar) to 
save library drawings off the system onto tape. 


If disk space is at a premium, you can delete the 
individual library drawings and just save the 
chips_ prt files for each component. 


If you must modify a component after you delete a 
library drawing, you can either: 


© Recreate the library drawing, incorporate the 
old and new information, and recompile the 
drawing. 

e Use a text editor to make changes directly to 
the chips_ prt file. 


Once you decide on a method of modifying compo- 
nents, whether updating and recompiling the library 
drawing or editing the chips_prt file, you should 
continue to update that component in the same way. 
If you edit chips_prt and make a correction one 
time, and then the next time you make a change you 
modify the archived library drawing, the change you 
made to the chips_prt file is lost when you recom- 
pile the drawing and recreate the file. Deciding on 
one archival method to use saves you from inadver- 
tently losing file changes. 
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The Simulation 
Model 


This section describes: 


Defining the simulation model 
General design rules for models 
Delay and pulse width standards 
Creating the model (checklist) 
Simulator primitives 

Simulation properties 


Modifying simulation models 


Simulation Model 


Defining the 
Simulation 
Model 


General Design 
Rules for Models 
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A simulation model emulates the behavior and opera- 
tion of a design without having to physically build 
the circuit. Simulation ensures the design’s quality 
early in the design process, when changes and cor- 
rections are easier and less expensive to implement. 


Simulation models are built from a specific set of 
parts called simulator primitives. You decide which 
simulator primitives to use by studying the func- 
tional specification and data tables in the appropri- 
ate data book. It is possible to create different simu- 
lation models (using different simulator primitives) 
for the same component, and obtain the same simu- 
lation results. 


There are several important goals you should keep 
in mind when designing simulation models: 


e Keep the model simple. Models do not need to 
reflect the complete logical behavior of the part 
in order to provide accurate information. Simple 
models are easier to design, easier to under- 
stand, easier to test, and execute faster. How- 
ever, the model should be as large and complex 
as necessary to make it easy to understand. 
Ease of understanding by the user is better than 
incremental improvements in execution. 


e Try to make the layout of the model follow the 

_ layout of the body. The interface signals in the 

model should appear in approximately the same 
physical relationship as on the body. 


e Try to make it possible to understand all error 
messages without having to refer to the model. 
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When applying this rule 
remember that for all 
practical purposes, NOT 
bodies are wires. 
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Reference everything back to the device itself 
(the component being modeled). 


The user will not understand the internal struc- 
ture of the models and does not want to have to 
look at them. Any errors during timing analysis, 
for instance, must be referred to signal names 
the user understands. This will not be the case if 
the model has a lot of unnamed signals. Models 
should always be designed so that error mes- 
sages are reported with signal names that mean 
something to the user. 


All timing checker primitives (such as MIN 
PULSE WIDTH and SETUP/HOLD) should have 
their inputs connected to interface signals. 
When this is not possible, signals internal to a 
model (local signals) should be given names that 
describe the signal. Checker bodies have negligi- 
ble impact on verification time. 


Do not connect sign—-extenders or mergers to the 
interface signals of a body. (This generates con- 
fusing synonyms.) Place a zero-delay, non- 
inverting buffer of the appropriate SIZE between 
such structures and the interface signal. 


Many parts have both a true and complement 
output. Simulator primitives have only a true 
output. To generate both outputs, use an invert- 
ing and a non-inverting buffer, one buffer driv- 
ing the complemented output and the other 
buffer driving the un-complemented output. 
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Delay and Pulse The following standards are used in calculating de- 


Width Standards lay and pulse width information for the simulation 
and timing models in the Valid libraries. 


Calculating Delays Data books frequently do not specify all three delay 
values (minimum, typical, and maximum). 
Table 4-1 shows how to calculate delay. values 
based on the available values. When two values are 
present, calculate both of the values listed. For the 
minimum or typical value, choose the lesser of the 
two values to represent the missing value. For the 
maximum value, choose the greater of the two val- 
ues to represent the missing value. 


Table 4-1. Calculating Delays 


One value present: Typical equals 


Minimum 2 times min 3 times min 
Typical 1/2 of typ 2 times typ 


Maximum 1/3 of max 1/2 of max 


Two values present, Use value of ak value of Use value of 
missing value is: Minimum Typical Maximum 


Minimum 1/2 of typ ~ 1/3 of max 


Typical 2 times min 1/2 of max. 


Maximum 3 times min 2 times typ 
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Data-Dependent Delays 


For a data-dependent 
delay example, see the 
LS244 simulation model. 


Open Collector Gates 


Pulse Width 
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Most delays are functions of the value of the data. 
Rise delay is usually different from fall delay. The 
library part models usually include both rise and fall 
delays. In models of tri-state parts, however, in- 
cluding both rise and fall delays would add to the 
complexity of the model. Therefore, tri-state parts 
are modeled with a single delay from enable to out- 
put, without consideration of whether the output is 
rising or falling. 


Open collector gates have no fixed, maximum time 
delay. It is not possible for the analysis program to 
compute the maximum delay from the GED drawing. 
It is up to the designer to calculate the explicit maxi- 
mum delay for each open collector gate. 


When an open collector gate is added to a GED 
drawing, the property MAX_DELAY appears above 
the body with a value of 10000ns. The designer 
must use the change command in GED to change 
this value to the required value. 


If minimum delays are not specified in the data 
book, use a minimum pulse width equal to one-half 
of the period of the input. For example, if the maxi- 
mum toggle frequency is 10 MHz, estimate the pulse 
width as follows: 


1 


Period = = 0.1x 10° 
10x 10° 
- 6 
Minimum pulse width = oo = 50 ns 
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One-Shots 


One-shots have no fixed pulse width. It is not possi- 
ble for the analysis program to compute the pulse 
width from the GED drawing. It is up to the designer 
to calculate the pulse width, taking into account all 
the one-shot tolerances, external component toler- 
ances, temperature variations, and drift over the life 
of the circuit. 


When a one-shot is added to a GED drawing, the 
property PULSE_WIDTH appears above the body with 
a value of 10000ns. The designer must use the 
change command in GED to change this value to 
the required value. 
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Creating the 
Model: 
Checklist 
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Creating a simulation drawing requires the same ba- 
sic steps as creating a logic drawing except that the 
parts used are logic simulator primitives from the 


Sim Library and support components from the Valid 
Standard library. 


1 Access the Sim library: 
library sim 


2 Create a drawing for your component with a 
.SIM extension (for example, 293.SIM). 


3 Add the required simulator primitives. 


4 Add a DRAWING body and attach the TITLE 
and ABBREV properties. 


5 Wire the model. 

6 Name the input and output signals. Signal 
names must include the \I interface signal 
property and correspond to the names of the 
signals in the body drawing for the part being 
modeled. 


¢ Assign the required simulation properties. 


8 Verify attachments, check, and write the 
model. 
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Use a B SIZE PAGE as a border. 
Center the drawing on the page. 


Include the name of the drawing and the in- 
itials of the creator in the boxes in the lower 
right hand corner of the page border. 


Enter the page number of the drawing as a 
note (text size 1.5) in the form “1 of 1.” 


Include a note block (notes enclosed with wires 
to form a block) to document any assumptions 
and/or critical design decisions that are not ob- 
vious to the user. 


Add primitives only from the Standard and 
Sim libraries. 


Every model must have a DRAWING body (with 
TITLE and ABBREV properties attached). 


Follow SCALD signal syntax for signal names. 


Do not use bit lists in bit subscripts. 


Make sure all interface signals have the \I 
property in the signal name. 


All interface signals should have an explicit 
width specified unless the signal is a scalar. 


All properties attached to bodies should be 
placed above the body or to the right. Place 
the properties one above the other and left- 
aligned. Display both the property value and 
name for all properties except PATH. 
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Since it is possible to create different simulator 
models for the same component, there is no step- 
by-step description for creating a simulation model 
for the TTL 293 component. Figure 4-1 shows one 
possible simulation model for the TTL 293. Simula- 
tor primitives and simulation properties are dis- 
cussed in general following the drawing. 


PRISE=CK! (5: 18) 163 
PRApL ace: ce: 15! 183, re: cia. 25.403 


SIZE=1B 
PELAV= tee 19> 163» (Gs 12) 16) 
Y. 


PRISE=CK: CS» 12, 16] 
PFALL=CK: £70 14. 21]eR: C13. 26s AF 


PRALL=ae £4)9) 143.Red 


Figure 4-1. TTL 293 Simulation Model 
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The Simulator 
Primitives 


For additional information 
on simulation primitives and 
directives, see the ValidSIM 
Reference Manual. 


Bubbled Pins 


Truth Table 
Abbreviations 
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The simulation primitives are stored in the Sim li- 
brary. Many simulator primitives are available, 
from simple logic gates to a complete ALU. The 
behavior of each primitive is understood by the 
Logic Simulator. 


Sometimes there are components and primitives that 
have similar names, for example, the “2AND” com- 
ponent and the “2 AND” primitive. Be sure to leave a 
space in the primitive names. 


Each input and output pin on a primitive can be in- 
dividually bubbled using the GED bubble command. 
Bubbling a primitive pin inverts the logical function 
of the primitive. An AND gate with a bubbled out- 
put behaves as a NAND gate. Bubbling the output 
pin of the simulator primitive BUF adds an inverter 
to your model. 


Table 4-2 shows the abbreviations used in the truth 
tables for the simulation primitives. 


Table 4-2. Truth Table Abbreviations 


Previous state 
Unknown value 
Can be any value 
High impedance 
Transition 
Not equal to 
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The Logic Gate There are three types of logic gate primitives: 
Primitives 

e AND 

e OR 

e XOR 


Since any pin of any primitive can be independently 
bubbled, to create a NAND gate, simply bubble the 
output of an AND gate. 


AND Primitive There are seven AND primitives (two-input through 
| eight-input): 


e@ 2 AND °e 6 AND 

PELAY=2 PELAY= 
e 3 AND e 7 AND 

° 4 AND e 8 AND 
‘alae 
DELAY=2 e 5 AND 
DELAY=2 7 een) Be sure to leave a space between the numeral and 
15 ‘“ 
the “AND.” 

is The truth table for an AND primitive is shown in 
ee Figure 4-2. 


One or More | All Other 
Inputs Inputs 


0 X 0 
1 1 1 
Z,U 1 U 


Figure 4-2. AND Gate Truth Table 
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OR Primitive There are seven OR primitives: 
DELAY=2 DELAY=2 e 20OR | e 6OR 
1B 1B 

= e 30R ° 70OR 

e 40OR e SOR 
een 

DELAY=2 e SOR 

1B 
ee The truth table for an OR primitive is shown in 
"= Figure 4-3. 

DELAY=0 

15 
DELAY=0 


Figure 4-3. OR Gate Truth Table 
XOR Primitive The XOR has only a two-input version. The truth 
table for an XOR primitive is shown in Figure 4-4. 


DELAY=2 
1B 


> 


Figure 4-4. XOR Gate Truth Table 
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The Buffer There are three buffer primitives: 
Primitives e BUF 
e TS BUF 
e IDENTITY 
BUF Primitive The truth table for the simple buffer primitive BUF 
is shown in Figure 4-5. 
DELAY=0 
3 input [Output 
Bu> 0 0 
| 1 1 
Z,U | U 
Figure 4-5. BUF Truth Table 
To create an inverting buffer, simply bubble the in- 
put or output pin of a buffer. Non-inverting buffers 
are commonly used for delays. 
10/1/89 
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TS BUF Primitive 


DELAY=0 
1B 


IDENTITY Primitive 


1B 
IDENTITY 
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The tri-state buffer primitive TS BUF has an enable 
input that, when disabled, causes the output to take 
the value high impedance (Z). The enable input has 
a width of one bit. The truth table for the TS BUF is 
shown in Figure 4-6. 


Figure 4-6. TS BUF Truth Table 


The IDENTITY primitive is similar to BUF except that 
it propagates the exact signal on the input pin to the 
output pin, while the BUF primitive converts the Z 
state to U and soft values to hard values. The truth 
table for the IDENTITY primitive is shown in 
Figure 4-7. 


Figure 4-7. IDENTITY Truth Table 
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The JK Primitive The JK primitive models the J-K Flip Flop. The 


primitive has the following features: 
DELAY=0 


e Input pins for J and K data inputs 


e Asynchronous set and reset functions 


e An edge-triggered clock 


If the clock input is not bubbled, then the primitive 
output triggers on a positive edge; if it is bubbled, it 
triggers on a negative edge. Outputs consist of Q 
and Q* data outputs. Asserting both the set and 
reset pins causes both of the outputs to go high. 
The truth table for the JK primitive is shown in 
Figure 4-8. 


-~=-90 OK KKK XK XK XK IG 
AO Oxxx xx x x |r 


a ot ket tl et OO OO OX 


Figure 4-8. JK Primitive Truth Table 
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_ The Latch Primitives 


LATCH Primitive 


PELAY=0 


LATC 


Two other latch primitives, 
SCAN LATCH and 

SCAN LATCH RS, appear 
in the Sim library. These 
primitives are no longer 
supported by Valid. 
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There are three latch primitives: 


e LATCH 
e LATCH RS 
e LATCH RS COMP 


The LATCH primitive has an enable input that is 
level—-sensitive. The truth table for the LATCH 
primitive is shown in Figure 4-9. 


Figure 4-9. LATCH Truth Table 
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LATCH RS Primitive The LATCH RS primitive has an enable input that is 
level-sensitive and asynchronous set and reset in- 
puts that cause the outputs to take the values one 
and zero, respectively. On the LATCH RS primitive, 
reset prevails over set if both are asserted. The 
truth table for the LATCH RS primitive is shown in 


s i Figure 4-10. 
pPRo 
va Tp [on 
EN, X ,U 
X 


N 
Cc 


X 
Xx 
X 
Xx 
ps 
p 
Xx 
0 
1 


a ee ee ee Se ee Sr a | 


n 
a | 


= 
wt 


Figure 4-10. LATCH RS Truth Table 
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LATCH RS COMP The LATCH RS COMP primitive has an enable input 
Primitive that is level-sensitive and asynchronous set and re- 
set inputs that cause the outputs to take the values 
one and zero, respectively. 


Complementary outputs are provided on the LATCH 
RS COMP primitive, and both outputs take the value 
one when both set and reset are asserted. The truth 
table for the LATCH RS COMP primitive is shown in 
Figure 4-11. 


0 
0 
1 
1 
1 
1 
1 
1 


a ot ot ot lot COO OU tCO CPX 


anh 
—_ 


Figure 4-11. LATCH RS COMP Truth Table 
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The Register 
Primitives 


REG Primitive 


DELAY=2 
1B 
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There are five register primitives: 


e REG e REG RS COMP 2 
e REGRS ° REG CKE 
e REG RS COMP | 


The register primitives have an edge-triggered clock 
input. When the clock input is not bubbled, the 
primitive outputs trigger on a positive edge; when 
the clock input is bubbled, the outputs trigger on a 
negative edge. The REG RS, REG RS COMP, and 
REG RS COMP 2 also have asynchronous set and re- 
set inputs that cause the outputs to take the values 
one and zero, respectively. 


The truth table for the REG primitive is shown in 
Figure 4-12. 


Figure 4-12. REG Truth Table 
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REG RS Primitive In the REG RS primitive, reset prevails over set if 
both are asserted. The truth table for the REG RS 
primitive is shown in Figure 4-13. 


[bata | Glock | PRY] CL | Output | 


DELAY=8 
1B 


X 
X 0 
X Z,U 1 U 
X 0 1 1 
=p 1 1 ps 
xp 1 1 U 
0 1 1 0 
1 1 1 1 
1 1 U 
1 1 ps 


Figure 4-13. REG RS Truth Table 


4-20 | 10/1/89 


Simulation Model 


REG RS COMP Primitive Complementary outputs are provided on the REG RS 
COMP, and both outputs take the value one when 
both set and reset are asserted. The truth table for 


the REG RS COMP primitive is shown in Figure 4-14. 
DELAY=2 


0 
0 
1 
1 
1 
1 
1 
1 


=a ot ot tl CUCU COX 


~ 
aS 


Figure 4-14. REG RS COMP Truth Table 
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REG RS COMP 2 The REG RS COMP 2 primitive is a special purpose 
Primitive version of the REG RS COMP primitive. The primi- 
tive works the same as the REG RS COMP primitive 
except that both outputs take the value zero when 
both s* and R* are asserted, and several additional 
conditions govern the behavior of preset and clear. 
The truth table for the REG RS COMP 2 primitive is 
shown in Figure 4-15. 


a os ot st ot OO OS OK 


0 
0 
1 
1 
1 
1 
1 
1 
1 


os 


Figure 4-15. REG RS COMP 2 Truth Table 


The following additional conditions override the val- 
ues in the REG RS COMP 2 truth table: 


e When an instance of the REG RS COMP 2 primi- 
tive has the body property DELAY attached 
with a value d, and when s* and rR” both 
change value from zero to one within d 
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or less of each other, then both T and T* take 
the value U. 


e When S* = U and LAST OUTPUT = 1, then 
T = 1 and T* = 0. 


e When S* = U and LAST OUTPUT + 1, then 
T = U and T* = U. 


e When R* = U and LAST OUTPUT = 0, then 
T = 0 and T* = 1. 


e When R* = U and LAST OUTPUT $ 0, then 
T = U and T* = 0. 


e When S* = U and R* = 0, then T = 0 and 


T* =U. 
REG CKE Primitive The REG CKE primitive is similar to the REG primi- 
DELAY=2 tive except that it has a clock enable input that en- 


ables the clock when asserted. 


10/1/89 4-23 


Simulation Model 


_ The Multiplexer There are three multiplexer primitives: 
Primitives ° 2 MUX 
e 4 MUX 
ag ae ee ° 8 MUX 


These multiplexer primitives have two, four, and 
eight inputs, respectively. The SELECT inputs for 
these parts have a fixed width of one, two, and three 
So bits, respectively. Using a multiplexer can often 
i6 dramatically reduce the number of simulator primi- 
tives needed to model a part. The truth table for the 
2 MUX is shown in Figure 4-16. The table can be 
extended readily for the 4 MUX and 8 MUX. 


Figure 4-16. 2 MUX Truth Table 


4-24 


10/1/89 


Simulation Model 


The MEMORY 
Primitive 


DEPTH=2 
DELAY=2 
1B 


See the ValidSIM Reference 
Manual for information on 
the MEM_STATE directive. 
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The width of each word in the MEMORY primitive is 
determined by the SIZE property. The number of 
words is determined by the DEPTH property. The 
A (address) input has a size corresponding to the 
number of words. For example, a 256-word RAM 
has an A input width of eight. 


As a convenience to the model builder, the 
WE (write enable) and CS (chip select) inputs on the 
MEMORY primitive are bubbled because most actual 
memory parts have these inputs low asserted. These 
pins can be unbubbled (using the bubble command 
in GED) if necessary. The MR (master reset) input, 
when asserted, clears the entire MEMORY to zeros. 


Memories can be modeled in either two-state or 
four-state mode. The default is four—state mode. 
In four-state mode, each bit of the memory assumes 
one of three states: zero, one, or U. Use the 
MEM_STATE directive to select two-state mode. In 
two-state mode, each bit of the memory assumes 
one of two states: zero and one. 


The truth table for two-state mode is shown in 
Figure 4-17. The truth table for four-state mode is 
shown in Figure 4-18. The OUTPUT column shows 
what value is output in each case. LOC means that 
the addressed location is output. The WRITE column 
indicates whether a write operation is performed. 
No indicates that no write operation is performed. 
A single letter indicates a write operation to the ad- 
dressed location, and the value written. All indicates 
that the given value is written to all memory 
locations. 
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TWO STATE MODE 
_MR | cs*| wet] AL OUTPUT! _WRITE | 
1 X Z no 
> = DEPTH 
UNDEF 
DEF 


0 
0 
0 
U 
U 
U 
1 
0 


ON CC a ee ae, 


co -- Cc 
CN C 


Figure 4-17. Two-State MEMORY Truth Table 
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| MR | cS*| WE*} As] OUTPUT| WRITE | 
1 X Xx Z no 


> = DEPTH U 
UNDEF 
DEF 


o- CC co oO Oo 


ON CC Cre = 


co-Cc 
CN C 


Figure 4-18. Four-State MEMORY Truth Table 
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The COUNTER SHIFT | The COUNTER SHIFT REGISTER primitive operates as 
REGISTER Primitive either a modulo-16 up/down counter or as a four-bit 
bidirectional shift register. This primitive has seven 


inputs: 
DELAY=2 
1B 


DI Parallel data in 
MSB IN _ Serial data input for shift right. This 


input produces two outputs: DO (data 
out) and TC (terminal count; active 


low). 

CET Count enable trickle input (active low). 
This input also acts as a serial input for 
shift left. 

CEP Count enable parallel input (active 
low) 

MR Master reset 

CK Clock 

This component is very S Select inputs (three bits) 


similar to the Fairchild 
100K ECL component 
(F100136). 
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The function of the COUNTER SHIFT REGISTER 
primitive is selected based on the S input as shown 
in Figure 4-19. 


FUNCTION 


Parallel Load 
Complement 
Shift Right 


Shift Left 
Count Down 
Clear 
Count Up 
Hold 


Figure 4-19. COUNTER SHIFT REGISTER Function Table 


The two count enable inputs are provided for ease of 
cascading in multistage counters. These two enable 
inputs must be both asserted for the count up/down 
operations. One count enable (CET) input also 
serves as a data input for the shift-left operation. 
The output also can be cleared asynchronously by 
bringing the master reset signal active. 
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The Arithmetic 
Primitives 


ADDER Primitive 
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There are five arithmetic primitives: 


e ADDER e CARRY SAVE ADDER 
e ALU e COMPARATOR 
e LOOKAHEAD 


The ADDER primitive takes three inputs: A, B, and 
CARRY IN; and produces four outputs: F, P, G, and 
CARRY OUT. The SIZE property determines the 
width of A, B, and F. F takes the sum of A, B, and 
CARRY IN. CARRY OUT is asserted if an overflow 
occurs. G is asserted if the addition of A and B 
generates a carry. P is asserted if the addition of A, 
B, and one propagates a carry. 
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ALU Primitive 


DELAY=0 
1B 


The ALU primitive is pat- 
terned after the Fairchild 
100181 ECL component. 
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The ALU primitive has inputs and outputs identical 
to those of the ADDER primitive with the addition of 
a four-bit select input that selects a function from 
the table shown in Figure 4-20. 


SELECT FUNCTION 


A plus B (BCD) 
A minus B (BCD) 
B minus A (BCD) 
0 minus B (BCD) 

A plus B 

A minus B 

B minus A 


oO 


0 minus B 
(A and B) or (-A and -B) 
(A and -B) or (-A and B) 
AorB 


OANA hh WN — 


Figure 4-20. ALU Select Table 


BCD stands for binary-coded-decimal. The behav- 
ior of the BCD functions is not defined for SIZE val- 
ues that are not multiples of four, or for data inputs 
that are not valid BCD values. Plus and minus denote 
two’s-complement arithmetic. A ‘—’ denotes one’s- 
complement. 
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LOOKAHEAD Primitive 


DELAY=0 
iB 


P Co 


LOOKAHEAD 


G 
Cy 


CARRY SAVE ADDER 
Primitive 


COMPARATOR Primitive 


DELAY=0 
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The LOOKAHEAD primitive is a look-ahead-carry 
generator with three inputs: P, G, and CARRY IN. 
The primitive produces one output, CARRY OUT. 
CARRY IN is one bit wide. P, G, and CARRY OUT 
are sizeable. Each CARRY OUT bit is the carry calcu- 
lated from CARRY IN and the P and G inputs from 
the least significant bit through the CARRY OUT bit 
of the primitive. 


The CARRY SAVE ADDER takes three inputs: A, B, 
and CARRY IN, and produces two outputs: T and 
CARRY OUT. All are sizeable. The two-bit sum is 
computed for each bit of A, B, and CARRY IN and is 
stored in the corresponding bits of CARRY OUT 
and T. T is the low-order bit of the sum, and 
CARRY OUT is the high-order bit of the sum. 


The COMPARATOR primitive takes two inputs, A and 
B, and produces three one-bit outputs: LT (B>A), EQ 
(A=B), and GT (A>B). LT is asserted if B>A. EQ is 
asserted if A= B. GT is asserted if A>B. 
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The Timing Checker 
Primitives 


Simulation speed is 
slower when these 
primitives are used. 


SETUP HOLD Primitive 


1B 
SETUP} SETUP=2@. @ 
HOLD HOLD=@. @ 


1B 
SETUP] SETUP=2. 0 
HOLD HOLD=. @ 
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Four timing checker primitives are available as 
simulation primitives: 


e SETUP HOLD 

e SETUP RISE HOLD FALL 
e EDGE TO EDGE 

e MIN PULSE WIDTH 


The TIMING_CHECK directive in the simulate.cmd file 
enables and disables the timing checker primitives. 
The TIMING_CHECK ON/OFF command can be used 
to enable and disable the primitives interactively 
during the simulation. 


The SETUP HOLD primitive has a clock and data in- 
put. For an active-high clock, it generates an error 
message in the output listing when the data input is 
not stable from SETUP ns before the rising edge of 
the clock until HOLD ns after the clock is high. The 
SETUP HOLD primitive has two default body proper- 
ties attached: 


SETUP = 0.0 
HOLD = 0.0 


The properties SETUP and HOLD are assigned the 
required property velues by using the GED change 
command. This primitive is used to check the set- 
up and hold times of registers and latches. 


The SETUP HOLD primitive has an optional enable 
input that turns checking on and off. If the enable 
input is any value other than ZERO, then checking is 
enabled. 


4-33 


Simulation Model 


SETUP RISE HOLD FALL 


Primitive 
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1B 
SETUP=2. 0 


HOLD=d. 8 


1B 
SETUP=0. 8 
HOLD=a. 0 


The SETUP RISE HOLD FALL primitive has a clock 
and data input. For an active-high clock, it gener- 
ates an error message in the output listing if the data 
input is not stable from SETUP ns: 


e Before the rising edge of the clock 
e While the clock is high 
e Until HOLD ns after the clock has gone low 


The SETUP RISE HOLD FALL primitive has two de- 
fault body properties attached: 


SETUP = 0.0 
HOLD = 0.0 


The properties SETUP and HOLD are assigned the 
required property values by using the GED change 
command. This primitive is used to check the set- 
up and hold times of data being written into 
memories. 


The primitive has an optional enable input that can 
be used to turn off checking. If the enable input is 
used, any value other than zero enables checking. If 
checking is enabled at any time between the rising 
edge and the falling edge of the clock, checking is 
performed for that clock pulse. 
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EDGE TO EDGE Primitive 


1B 
MIN=0. @ 
MAX=0. @ 


1B 
MIN=2. 2 
MAX=2. @ 


MIN PULSE WIDTH 
Primitive 


1B 
PULSE} LOW=2. 0 
WIDTH| HIGH=0. 2 


1B 
LOW=2. @ 
HIGH=0. @ 


10/1/89 


The EDGE TO EDGE primitive has two inputs, CK1 
and CK2. It checks that the RISING edge on CK2 is at 
least a minimum delay from the RISING edge on CK1 
and no more than the maximum delay. The EDGE 
TO EDGE primitive has two default body properties: 


MIN = 0.0 
MAX = 0.0 


The properties MIN and MAX are assigned the re- 
quired property values by using the GED change 
command. Use only rising delays. 


The primitive has an optional enable input that turns 
the checking on and off. If the enable input is any 
value other than zero, checking is enabled. If check- 
ing is enabled any time during the rising edge of 
CK1i, then checking is performed for that edge. If 
there is no edge on CK2 (that is, if CK2 does not 
change state), then no error message is generated. 


The MIN PULSE WIDTH primitive has one data input. 
It checks that its data input has no pulses on it that 
are low for less than LOW ns, and no pulses on it 
that are high for less than HIGH ns. The MIN PULSE 
WIDTH primitive has two default body properties: 


LOW = 0.0 
HIGH = 0.0 


The properties LOW and HIGH are assigned the re- 
quired property values by using the GED change 
command. 


The primitive has an optional enable input that turns 
checking on and off. If the enable input is any value 
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other than zero, checking is enabled. If checking is 
enabled any time during a given pulse, then the 
width of that pulse is checked. 


The Encoder and There are four encoder/decoder primitives: 


Decoder Primitives 
e 8 BIT PRIO ENCODER 


e PRIORITY ENCODER 
e 1 OF 8 DECODER 
e 8 BIT DECODER 


8 BIT PRIO ENCODER The 8 BIT PRIO ENCODER primitive takes an eight-bit 
Primitive input and produces two outputs: T, which is three 
ae Aven bits wide and ANY, which is one bit wide. ANY is 


asserted if any input bit is asserted. T is the bit 
number of the most significant bit asserted, if any, 
where zero is the most significant input. 


PRIORITY ENCODER The PRIORITY ENCODER primitive takes eight one- 
Primitive bit inputs, I7..10, and produces two outputs: T, which 
DELAY=0 DELAY=2 is three bits wide, and ANY, which is one bit wide. 
PRIORITY ANY is asserted if any input bit is asserted. T is the 

17 ENCODER 


Is Tae bit number of the most significant input which is 
asserted, if any, where I7 is the most significant in- 


put and has a bit number of seven (111 binary). 
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1 OF 8 DECODER 
Primitive 


DELAY=0 


i = defined value 


(0/1,2/U,0/1) etc. 


i = defined value 


(0/1,2/U,0/1) etc. 


8 BIT DECODER 
Primitive 
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The 1 OF 8 DECODER primitive takes two inputs: 
SELECT (I<2..0>), which is three bits wide, and 
OUTPUT ENABLE, which is one bit wide. It produces 
an eight-bit output T<7..0>. If OUTPUT ENABLE is 
asserted, SELECT selects which bit of T is asserted. 
When SELECT contains Z and/or U, those SELECT 
bits are treated as “don’t care” for selecting output 
bits and the selected output bits are set to U. 


all bits 0 
the i-th bit U and the rest 0 
the (0/1,*,0/1)-th bits U and the rest 0 
the i-th bit 1 and the rest 0» 
the (0/1,*,0/1)-th bits U and the rest 0 


The 8 BIT DECODER primitive is identical in opera- 
tion to the 1 OF 8 DECODER primitive except for the 
output of the primitives. The output of the 1 OF 8 
DECODER is an eight-bit bus. The output of the 
8 BIT DECODER is eight individual bits. 
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Other Primitives There are four other Simulator primitives: 


e PARITY 

e RES 

e PASS TRANSISTOR 

e UNI PASS TRANSISTOR 


PARITY Primitive The PARITY primitive’s I input can be sized and pro- 
DELAY=2 duces a one-bit output T. T is one if the total of the 
asserted (one) inputs is odd. 
I T 
PARITY 
RES Primitive The resistor primitive RES is fully bidirectional and 
acts like a wire except that HARD strength signals 
: _ are converted to SOFT strength when they pass 
through. RES primitives always have zero delay. 
The RES primitive is sizeable and the pins cannot be 
RES | bubbled. 
WA- 
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PASS TRANSISTOR 
Primitive 


DELAY=2 
=r 
= 


iL DELAY=@ 
t 


DELAY=0 


UNI PASS TRANSISTOR 
Primitive 
DELAY=2 
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The PASS TRANSISTOR primitive is fully bidirectional 


and acts like a switch. The G pin of the PASS 
TRANSISTOR controls whether the A and B pins are 
connected together. An active G pin (zero if the pin 
is bubbled, otherwise one) causes the PASS 
TRANSISTOR to act like a wire, connecting the A and 
B nets. An inactive G pin causes the PASS 
TRANSISTOR to act as if it were not in the circuit. 
The delay from A to B or B to A is always zero. The 
G pin has an input delay that assumes the value of 
the DELAY property on the PASS TRANSISTOR. The 
A and B pins of the PASS TRANSISTOR are sizeable 
and are not bubbled. The G pin is always one bit 
wide and can be bubbled. 


The UNI PASS TRANSISTOR is a unidirectional ver- 
sion of the PASS TRANSISTOR and results in more 
rapid simulation for MOS circuits. Pins and proper- 
ties of the UNI PASS TRANSISTOR primitive are iden- 
tical - a G pin that controls whether the A and B 
pins are connected. However, because this transis- 
tor is unidirectional, the A pin is an input pin rather 
than an output. 
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The FLAG Primitive 


~) 
: 


=> 


00 


<I 
c>- 


User—coded 
Primitives 


4-40 


There are twelve different versions of the FLAG 
primitive. The first four versions are primary input 
flags. The second four versions are primary output 
flags. The last four versions are bidirectional flags. 


The FLAG primitives are used for formatting the 
Primary I/O Trace program information. To use the 
trace program, each primary 1/O signal must be des- 
ignated on the top level schematic (the root drawing) 
with a FLAG body. 


The question mark identifies the PATH property at- 
tached to the primitive. The PATH gets written auto- 
matically; you do not have to define the property. 


The Simulator allows you to code simulator models 
in Pascal or C and refer to them using standard 
SCALD drawings. Existence of these user-coded 
primitives (UCPs) means that you can expand the 
“parts set” understood by the Logic Simulator. For 
more information on user-coded primitives, see the 
Validsim Reference Manual. 
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Simulation 
Properties 
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When creating simulation models, you can size 
simulation bodies and add delay values to each 
primitive using body and pin properties. Simulation 
body properties are: 


e DELAY 
e RISE 
e FALL 
e SIZE 


Pin-to-pin delays are specified using the pin 
properties: 


e PDELAY 
e PRISE 
e PFALL 


Simulation models can carry body properties and 
pin properties simultaneously. When the delays 
through a primitive are all one set of values except 
for a single delay path, the one path can be speci- 
fied using the pin properties, and the other delays 
can be specified using the body properties. For de- 
signs where delays are related to changes in output 
loading, temperature, and voltage, the Delay Estima- 
tor and Expression Evaluator can be used. 


Table 4-3 summarizes the most common simulation 
properties. For detailed information on simulation 
properties and directives, refer to the Validsim 
Reference Manual. 
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Table 4-3. Simulation Properties 


Prop Prop Controlling 
Type | Name Directive(s) | Comments 
Body Body properties attach to the origin of a primitive to 
control the size or delay time of the primitive. 


DELAY | DELAY_MODE| Specifies the delay time as a single value or the rise/fall 
RISE_FALL | delay values as [min,typ,max]. DELAY _MODE directive 


selects which value to use for current simulation run; 
max is the default. DELAY property is the default delay 
value used if RISE_FALL directive is OFF. 
= RISE_FALL 
FALL RISE_FALL 


7 PIN_DELAY 


Samad (ian FALL 


Can be attached in addition to DELAY property. When 
directive is ON (default), RISE delay overrides DELAY 
property. 


Can be attached in addition to DELAY property. When 
directive is ON (default), FALL delay overrides DELAY 
property. 


Specifies the number of bits on a pin. Can also use 
SIZE=SIZE to match primitive size to the SIZE property 
attached to the body drawing. 


Pin delay properties are allowed on both input and output 
pins. The PIN_DELAY directive affects all of the pin de- 
lay properties; when the directive is ON, pin delay prop- 
erties override body delay properties. If PDELAY is not 
defined and the RISE_FALL directive is OFF, the maxi- 
mum value between PRISE and PFALL is used. 


PDELAY overrides PRISE and PFALL when the RISE_FALL 
lame is OFF. 


RISE_FALL | PRISE and PFALL override PDELAY when the RISE_FALL 
directive is ON. 


PFALL RISE_FALL | PRISE and PFALL override PDELAY when the RISE_FALL 
directive is ON. 


4-42 10/1/89 


Simulation Model 


Simulation Body 
Properties 


The DELAY Property 


SYNTAX 


Simulation body properties are attached to the origin 
of the primitive and control the behavior of the en- 
tire primitive. 


Delays are given in nanoseconds. Primitives without 
an explicit DELAY are assumed to have a delay of 
zero. By convention, primitives are given delays to 
model the worst-case behavior of the part being 
modeled, but this is not required. The syntax of the 
DELAY property in simulation models is: 


DELAY=[min,typ,max],[min,typ,max] 


Rise delay (the first set of values) and fall delay (the 
second set of values) define the rise and fall times 
of the output of the signal. The min, typ, max delays 
must be enclosed in square brackets and separated 
by commas. If the rise and fall delay values are the 
same, only one [min, typ, max] entry is required. 


The Simulator’s DELAY MODE directive selects 
which of the three delay values is used for the cur- 
rent simulation run (min, typ, or max; the default is 
max). 


For the Simulator to function correctly, the simula- 
tion model must represent one of the possible timing 
behaviors for the component. Exercise care when 
specifying delay values; in particular, zero-delay 
components can result in unexpected behavior in a 
circuit. 
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The RISE Property 


The FALL Property 


The SIZE Property 
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In addition to using the DELAY property, rise delays 
can be specified using the RISE body property with a 
rise delay time value. If the DELAY and RISE prop- 
erties are both attached to a body, the Simulator’s 
RISE_FALL directive selects which delay value is 
used. 


In addition to using the DELAY property, fall delays 
can be specified using the FALL body property with 
a fall delay time value. If the DELAY and FALL 
properties are both attached to a body, the 
Simulator’s RISE_FALL directive selects which delay 
value is used. 


Most simulator primitives can have a SIZE property 
to specify the number of bits on a pin. For exam- 
ple, to compute the sum of two 16-bit signals, a sin- 
gle adder primitive with a SIZE of 16 can be used 
instead of 16 adder primitives. A primitive can be 
given the property SIZE=SIZE, which means that the 
size of the primitive is taken from the SIZE property 
attached to the part being modeled. Two special 
primitives, the 8 BIT PRIO ENCODER and the 1 OF 8 
DECODER have a fixed SIZE of eight bits. 


Many primitives have inputs and outputs that are not 
affected by the SIZE property. All enable inputs, 
clock inputs, and chip select inputs have a fixed 
width of one bit. The select input of an eight-bit 
multiplexer is always three bits wide. 
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Simulation Pin 
Properties 
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For complex primitives with multiple input and out- 
put pins, accurate modeling of the delays within the 
primitive is tedious if not impossible. The pin-to- 
pin delay feature allows you to associate separate 
delay values for individual paths from input pin to 
output pin. 


Pin delay properties are allowed on both input and 
output pins. Any conflict between input pin proper- 
ties and output pin properties (two different delay 
values specified for one pin-to-pin path) is reported 
as an error. Delay values specified between two in- 
put pins or two output pinss are also reported as an 
error. 


To override the specified body DELAY properties on 
a model and use the pin delay properties, add the 
directive PIN_DELAY ON to the simulate.cmd file (the 
directive is OFF by default). This directive controls 
whether the model uses the DELAY, RISE, and FALL 
properties or PDELAY (pin delay), PRISE (pin rise de- 
lay), and PFALL (pin fall delay). When the directive 
is ON, pairs of input and output pins use the body 
DELAY properties if pin delays are not specified. 
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Modifying 
Simulation 
Models 
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Simulation models are designed to correctly model 
the part while including no extraneous data. The 
smaller the model, the faster the Simulator can run. 
Models are therefore difficult to intuitively grasp; 
make as few changes to models as absolutely neces- 
sary. The most frequent change to a simulation 
model is the change of the value of a delay property. 
Use the change command in GED to change the 
value. Be careful to change the correct instance of 
the delay property in the model. To accommodate 
different delay paths through the device, propaga- 
tion delays are usually divided up and placed in dif- 
ferent locations in the model. Examine the model 
carefully to choose which delays you need to change. 
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The Timing Model 


This section describes: 


Defining the timing model 
Creating the model (checklist) 
Timing primitives 

Timing properties 


Modifying timing models 


Timing Model 


Defining the 
Timing Model 


Timing models reflect the timing behavior of a design. 
Models are built as simply as possible so that the 
Timing Verifier runs quickly and efficiently. Timing 
models therefore focus on timing characteristics and 
do not exhaustively simulate the logical behavior of 
the component. 


Timing models are built from a specific set of parts 
called timing primitives. You decide which timing 
primitives to use by studying the functional specifi- 
cation and data tables in the appropriate data book. 
It is possible to create different timing models (using 
different timing primitives) for the same component, 
and obtain the same timing results. 


Timing models need to correctly model the delays of 
all signals through the component (propagation de- 
lay). For clocked and complex components, the 
model must check: 


e Setup and hold times 
e Pulse width 
e Edge to edge time (when appropriate) 


When designing timing models, you should keep cer- 
tain goals in mind. These goals are the same as 
those for designing simulation models and are 
described under “General Design Rules for Models” 
in Section 4, The Simulation Model. The standards 
used in calculating delay and pulse width informa- 
tion for the timing models are also the same as 
those described under “Delay and Pulse Width Stan- 
dards” in Section 4. 
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Creating the 
Model: 
Checklist 
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Creating a timing drawing requires the same basic 
steps as creating a logic drawing except that the 
parts used are timing primitives from the Time li- 
brary or components from the Standard library. 


1 Access the Time library: 


library time 


2 Create a drawing for your component with a 
.TIME extension (for example, 293.TIME). 


3 Add the required timing primitives and a 
DRAWING body (with TITLE and ABBREV 
properties). 


4 Add a PINNAMES component. This compo- 
nent accesses the .BODY drawing, collects all 
the pin names assigned to the body, and lists 
them beneath the PIN_NAMES header. All 
pins identified on the logic drawing must be 
accounted for on the timing model. 


5 Wire the model. 


6 Name the input and output signals. Signal 
names must include the \I interface signal 
property and correspond to the names of the 
signals in the body drawing for the part being 
modeled. 


7 Assign the required timing properties. 


8 Verify attachments, check, and write the 
model. 
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Standards 


X 


Y VY VN 


Use a B SIZE PAGE as a border. 
Center the drawing on the page. 


Include the name of the drawing and the in- 
itials of the creator in the boxes in the lower 
right hand corner of the page border. 


Enter the page number of the drawing as a 
note (text size 1.5) in the form “1 of 1.” 


Include a note block (notes enclosed with wires 
to form a block) to document any assumptions 
and/or critical design decisions that are not ob- 
vious to the user. 


Add primitives only from the Standard and 
Time libraries. 


Every model must have a DRAWING body (with 
TITLE and ABBREV properties attached). 


Every model should have a PIN NAMES body. 
Follow SCALD signal syntax for signal names. 


Do not use bit lists in bit subscripts. 


Make sure all interface signals have the \I 
property in the signal name. 


All interface signals should have an explicit 
width specified unless the signal is a scalar. 


All properties attached to bodies should be 
placed above the body or to the right. Place 
the properties one above the other and left- 
aligned. Display both the property value and 
name for all properties except PATH. 
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Since it is possible to create different timing models 
for the same component, there is no step-by-step 
description for creating a timing model for the 
TTL 293 component. Figure 5-1 shows one possible 
timing model for the TTL 293. Timing primitives 
and timing properties are discussed in general fol- 
lowing the drawing. 


Figure 5-1. TTL 293 Timing Model 
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The Timing 
Primitives 


For additional 
information on timing 
primitives and properties, 
see the ValidTIME 
Reference Manual. 


Bubbled Pins 


The timing primitives are stored in the Time library. 
‘There are three groups of timing primitives: 


e Standard function primitives (based on func- 
tions like gates and flip-flops) 


e Non-standard functions useful for timing 
models 


e Error-checking primitives added to models to 
detect timing errors 


Sometimes there are components and primitives that 
have similar names, for example, the “2AND” com- 
ponent and the “2 AND” primitive. Be sure to leave 
a space in the primitive names. 


Each input and output pin on a primitive can be in- 
dividually bubbled using the GED bubble command. 
Bubbling a primitive pin inverts the logical function 
of the primitive. This allows you to create inverting 
buffers, NAND gates, NOR gates, negative-edge- 
triggered registers, and so on. For example, bub- 
bling the output pin of the timing primitive BUF adds 
an inverter to your model. 
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Truth Table Table 5-1 shows the abbreviations used in the truth 
Abbreviations tables for the timing primitives. 


Table 5-1. Truth Table Abbreviations 


Constant 
Fall 
Previous state 
Rise 

Stable 

Unknown value 
Can be any value 
High impedance 
Transition 
Not equal to 


In cases where more than one entry applies to a 
given set of input conditions, the first entry takes 
precedence. 
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Standard Function 
Primitives 


AND Primitive 


These time primitives are based on familiar SSI and 
MSI components. They perform some (not all) of 
the functions of these parts. There are 11 standard 
function primitives: 


e AND e REG 
e OR e REG RS 
e XOR e 2 MUX 
e LATCH e 4 MUX 
e LATCH RS e 8 MUX 
e TS BUF 

There are eight AND primitives: 
e AND e 5 AND 
e 2 AND e 6 AND 
e 3 AND e 7 AND 
e 4 AND e 8 AND 


The truth table for an AND primitive is shown in 
Figure 5-2. 


| AND}O 1 #S R F CU 2Z 
0 0 0 0 0 0 0 0 0 
1 0 1 Ss R F C U U 
S 0 S S R F C U U 
R 0 R R R C Cc U U 
F 0 F F C F C U U 
Cc 0 C C C C C U U 
U 0 U U U U U U U 
Zz 0 U U U U U U U 


Figure 5-2. AND Primitive Truth Table 
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OR Primitive There are eight OR primitives: 
= e OR e 5 OR 
Je om) e 20R e 6 OR 
e 30OR e 7OR 
e 40OR e 8 OR 


\3 i 


The truth table for an OR primitive is shown in 
Figure 5-3. 


8 OR 


Ye Ue GU 
\3) & 


cceo7m o7m-7 | TN 
cCccqgqgqg 0070 10 
ceec coc le 
cecc ccc IN 


ceogqo wvI- wD 


S 
1 

S 
R 
= 
Cc 
U 
U 


fOR| O 1 +S R 
0 ‘ 
1 
Ss 
R 
F 
Cc 
U 
Zz 


Figure 5-3. OR Primitive Truth Table 
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XOR Primitive The XOR has only a two-input version. The truth 


table for an XOR primitive is shown in Figure 5-3. 


cCccogqg O0OT7TD |B 
ccoqgqgo ogDvT | TN 
ccogqgqg 09000 19 
Cee: 3 -e-C.c Fe 
ecec -C.e cc | 'N 


S 
S 
S 
S 
C 
C 
Cc 
U 
U 


Figure 5-4. XOR Primitive Truth Table 
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LATCH Primitive The LATCH primitive has a data input and an enable 
i input. The primitive is affected by the value of the 
TRANSITION property and the value of the Timing 
ak Verifier’s LATCH_ERR_MODEL directive. The truth 

LATCH 


tables for the LATCH primitive are shown in 
i Figure 5-5 and Figure 5-6. When enable is bub- 
bled, the inverse of the truth table applies. 


LATCH 


EN | Last Output ee 


0,1,S 
R,F,C,U,Z . 


Oo Oo 


0,1,S5,R,F,C 
X U,Z 
= DATA 0,1,U,Z 
S S 


= DATA All other conditions 
3 DATA U,Z 

0 1,8 

1 0,S 


R,F,C,U,Z 0,1,S 
R,1 R 
F,0 F 
All other conditions All other conditions 


= DATA 0,1,5,U,2Z 
= DATA R,F,C 
X U,Z 
0 1,8 


Figure 5-5. LATCH Truth Table (Part 1) 


1 

1 

R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
F 
F 
F 
F 


If there has been no data transition since EN was last 1 or R and the latch 
is being simulated SMOOTH. 
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R,1 
F,O 


All other conditions All other conditions 
= DATA X 
3% DATA 0,1,S 
1 R 


0 
x 1 
7% 0 

X 


All other conditions All other conditions 
Xx U,Z 
= DATA 0,1,S,R,F,C 
All other conditions All other conditions 


cc oFcec 2007 2H 


Xx X 
X X 


Figure 5-6. LATCH Truth Table (Part 2) 


FE 
F 
F 
FE 
Fe 
Ss 
S 
S 
S 
S 
Ss 
S 
S 
C 
Cc 
C 
Z 
U 


If the DATA undergoes a transition while the latch is 
closing (the ENABLE signal has the value F), then a 
setup/hold time violation has occurred. Under these 
conditions, the signal values are calculated as OPEN, 
CLOSED, or CONSERVATIVE, depending on the value 
of the LATCH_ERR_MODEL directive. The default 
value is CONSERVATIVE. Figure 5-7 shows the 
truth tables for each of the three values of the 
LATCH_ERR_MODEL directive. 
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LATCH_ERR_MODEL = OPEN 
Last EN Last Output 


S,R,F,U,Z 
R,1 
F,O 
All other conditions 


LATCH_ERR MODEL = CLOSED 
LastEN| Last Output | Data 
F R,F,C,U,Z X 


LATCH_ERR_MODEL = CONSERVATIVE 


LastEN| Last Output | Data 


F 
F 
F 
F 
F 
F 
F 
F 


S,R,F,C,U,Z 


R,1 


Figure 5-7. LATCH_ERR_MODEL Truth Table 


The LATCH primitive has the default property 
TRANSITION=GLITCHY. When the LATCH is clocked, 
the output of the LATCH always changes, even when 
the input remains stable. If the property 
TRANSITION=SMOOTH is attached to the LATCH, the 
output of the LATCH does not change when the 
LATCH is clocked and the input remains stable. 
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LATCH RS Primitive The LATCH RS primitive is a LATCH primitive that 
has asynchronous set and reset inputs. First the 
LATCH output is computed for the current input val- 
ues, then the SET/RESET function is applied to the 
outputs. The SET/RESET function inherits the state 
of the TRANSITION property (SMOOTH/GLITCHY) 
and functions differently depending on the value. 
Figure 5-8 shows the truth table for the SET/RESET 
function in GLITCHY mode. Figure 5-9 shows the 


The CHG function is truth table for the SET/RESET function in SMOOTH 
discussed on page 5-23. mode. 


SET/RESET in GLITCHY MODE 
RESET SET OUTPUT NEW OUTPUT 


OLD OUTPUT 


— < Oooo o00 0 


3 SET 
x SET 


1,8 
R,F,C 
U,Z 
conditions 


, 
1 
C 
S 
C 
U 
U 
0 
0 
C 
U 
S 
C 
U 
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SET/RESET in SMOOTH MODE 
RESET SET OUTPUT NEW OUTPUT 


OUTPUT 


CTHHHWH D-*X& CODCOD ADCO 


DDD NO 


1 

1 

R 
S 
Cc 
U 
C 
U 
0 
0 
F 
S 
Cc 
U 
Cc 
U 
F 
Cc 
U 


ran" OoOoOooaoeo OO 


nm. 7 
DDD 


Figure 5-9. SET/RESET in SMOOTH Mode Truth Table 
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TS BUF Primitive 


1B 


a 


See the ValidTIME Reference 
Manual for more information 
on Timing Verifier directives. 
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The tri-state buffer primitive has two inputs, data 
and enable. The data input and output signals are 
affected when you attach the SIZE property to the 
TS BUF primitive; the enable signal is common to all 
buffers. 


The default operating mode for the TS BUF primitive 
is known as tri-state mode. When the enable is 
STABLE, the output is unknown. This is a conserva- 
tive model of tri-state behavior. The alternate oper- 
ating mode is called wire-or mode. This mode is less 
conservative and accommodates designs in which 
the enable signal is specified as STABLE/CHANGING. 


Mode selection for the TS BUF primitive is controlled 
by the Timing Verifier’s TS_BUF_TYPE directive. 
Figure 5-10 shows the truth tables for tri-state 
mode and wire-or mode for the TS BUF primitive. 
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Enable Input 


TRI- Ar MODE 


oO 


cCccaqaq anoaOo | 
CCcCQQ NONN0I10 
Coee ee cS |e 
eccc ccec |N 


1 

0 
, 

S 
R 
F 
Cc 
U 
U 


SoS SC ees 
cCccogqgqgqaoa0gq0ndn 


a MODE 


oO 


ccotm vaHMHA0];— 
Ccogdgqg NO000]% 
cCccagqqg aaQaNOoOI!TN 
ccoo QAN0N010 
ecccec ceceeclc 
eeqcac ¢cce cl N 


cco Dwa-7 O 


- Enable Input 
Figure 5-10. TS BUF Truth Tables 


If you tie together the outputs of two or more TS BUF 
primitives, you create a tri-state bus, or TS BUS. The 
TS BUS is a special type of primitive because it is not 
represented by a GED drawing. You cannot add a 
TS BUS to a timing model. A TS BUS is shown in 
Figure 5-11. 
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Figure 5-11. TS BUS Primitive 


Because the drivers are tri-state and share the use 
of the BUS by means of separate ENABLE signals, 
the logical function represented is not the same as 
that of a wire-gate. With a tri-state bus, the only 
two meaningful configurations are: 


e Only one TS BUF is enabled at a time 


e If two are enabled, they carry identical output 
signal values : 


Almost all other conditions produce the signal value 
U (unknown) on the bus. 


The Timing Verifier evaluates this circuitry in accor- 
dance with the tables shown in Figure 5-12. The 
TS BUS, like the TS BUF primitive, operates in tri- 
state mode by default but can also operate in wire- 
or mode. Mode selection for the TS BUS is con- 
trolled by the TS_BUF_TYPE directive. 
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Figure 5-12. TS BUS Tables 
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REG Primitive 


a ie The REG primitive implements a rising edge trig- 
Da DG gered register. The truth table for the REG primitive 
"REG REG differs depending on the value of the clock signal. 
. . The tables are shown in Figure 5-13. 


REG when CLOCK = 1 


Last Clock Input _ penoues [Next Output 


LAST OUT 

R 

F 

s* 

S 
LAST OUT 
LAST OUT 
LAST OUT 

S 
LAST OUT 


~0,1,S 
LAST OUT 
LAST OUT 


REG when CLOCK = CorR 


ces | input |Last cutee |Next Output _ 
0,1 


— OUT 


eo 


REG when CLOCK = S orF 


Last Clock | _Input__|__Last Output__|_Next Output_ 


Xx X 3 0,1,S S 
Xx Xx 0,1,S LAST OUT 
REG when CLOCK = U or Z 
Last Clock| Input | _Last Output__| Next Output | 


Figure 5-13. REG Truth Tables 


. If the REG is smooth and there were no input transitions. 
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REG RS Primitive 


2 MUX, 4 MUX, 8 MUX 
Primitives 
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When the REG primitive has the property 
TRANSITION=GLITCHY and the REG is clocked, the 
output of the REG always changes, even when the 
input remains stable. When the REG primitive has 
the property TRANSITION=SMOOTH, the output of 
the REG does not change when the REG is clocked 
and the input remains stable. 


The REG RS primitive is the same as the REG primi- 
tive except that it also has asynchronous reset and 
set inputs. First, the REG output is computed for the 
current input values, then the SET RESET function is 
applied to the output. 


The SET/RESET function inherits the state of the 
TRANSITION property (SMOOTH/GLITCHY) and func- 
tions differently depending on the value. The 
REG RS primitive uses the same SET/RESET truth 
tables as the LATCH RS primitive. The truth tables 
for the SET/RESET function are shown in Figure 5-8 
(page 5-14) and Figure 5-9 (page 5-15). 


The 2 MUX, 4 MUX, and 8 MUX primitives implement 
two-input, four-input, and eight-input multiplexers, 
respectively. If any of the select inputs on these 
multiplexers has a known value of zero or one, then 
only the possibly selected state inputs are considered 
when calculating the output value. If more than one 
data input might be selected, the output value is cal- 
culated by using the CHG function on the set of se- 
lected data inputs. 


If the MUX has no TRANSITION property or if 
TRANSITION=GLITCHY, then any input transition 
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causes an output transition of the appropriate slope. 
If TRANSITION=SMOOTH, then if the output state be- 
fore and after an input transition is the same, there 
iS no Output transition. 


The non-standard time primitives are particularly 
suited to modeling timing functionality. Some of 
these primitives (such as BUF and RES) are familiar 
components, but may be used somewhat differently 
in a timing model. Others (such as CHG) were cre- 
ated especially for the Timing Verifier. These 
components: 


e Attach delay properties to various parts of a 
model 


e Provide accurate load calculations 


e Assure efficient and correct functioning of the 
model 


There are seven non-standard function primitives: 


e CHG e THRESHOLD 

e BUF e TRANSMISSION GATE 
e IDENTITY e UNI TRANS GATE 

e RES 
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CHG Primitive ' |The most important non-standard primitive is the 
1B CHG (change) primitive. This primitive tells you 


-) oe) : 1B whether an input signal is stable, changing, or un- 


known; frequently, this is all the information the 


Timing Verifier needs. When you add delay to the 
> CHG primitive, you effectively model simple propa- 
: gation delay through a component. 

1B For example, to model the propagation delay from 
=)>- " the A and B inputs to the sum (Y output) of an ad- 
der, use the CHG primitive and attach the appropri- 

1B poe ate DELAY property. This model is very simple be- 
+3 cause the delay through this component is the same 


regardless of the values being added. Adding in the 
appropriate delay for CARRY IN complicates the 
model only slightly. 


The truth table for a CHG primitive is shown in 
Figure 5-14. 
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Figure 5-14. CHG Primitive Truth Table 
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BUF Primitive The BUF primitive is used as a convenient place to 
attach delay properties in a model. It is also used to 
1B isolate outputs so that correct load calculations can 
be performed. The value of a signal is not changed 
by the BUF primitive (except the value Z). Buffers 
are also used to isolate outputs for correct. load 

checking. 


The truth table for the BUF primitive is shown in 
Figure 5-15. 


Figure 5-15. BUF Truth Table 


To create an inverting buffer, simply bubble the in- 
put or output pin. Non-inverting buffers are com- 
monly used for delays. 
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IDENTITY Primitive 


1B 
IDENTITY 


RES Primitive 


RES 
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The IDENTITY primitive is a special case of the BUF 
primitive. It retains the identity of all signal values 
including Z. It also retains the signal strength of all 
input signals. 


The truth table for the IDENTITY primitive is shown 
in Figure 5-16. 


Figure 5-16. IDENTITY Truth Table 


The resistor primitive RES has the same truth table 
as the IDENTITY primitive. However, the RES primi- 
tive converts the strength of HARD input signals to 
SOFT signal strength. Since most other signal 
strengths in a design are HARD, this means that the 
value of the RES output can be overridden by a com- 
peting HARD value. This primitive is used to assure 
the correct modeling of circuits using pull-up resis- 
tors. For HARD and SOFT input strengths, the RES 
outputs a SOFT signal strength; for UNDRIVEN input 
strengths, the RES outputs an UNDRIVEN signal 
strength. 
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THRESHOLD Primitive 


TRANSMISSION GATE 
Primitive 


6% 1B oul 
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The THRESHOLD primitive has a threshold input and 
a single output pin. The primitive behaves some- 
what like an input-state (0 or 1) detector. Its output 
remains changing until its threshold input is as- 
serted. This primitive is seldom used. 


The truth table for the THRESHOLD primitive is 
shown in Figure 5-17. 


Figure 5-17. THRESHOLD Truth Table 


The TRANSMISSION GATE primitive has an enable 
input (EN) and two bidirectional pins (T1 and T2). If 
the enable input is zero, then both T1 and T2 are set 
to high impedance (Z). If the enable input is one, 
then Ti and T2 are tied together using the same 
function as the TS BUS (see page 5-17). 
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~ UNI TRANS GATE 
Primitive , 


Error-—Checking 
Primitives 


SETUP HOLD Primitive 


1B 
SETUP} SETUP=0.0 
HOLD HOLD=2. @ 


1B 
SETUP] SETUP=2. 2 
HOLD HOLD=. @ 
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The UNI TRANS GATE primitive is a uni-directional 
transistor. It has a gate input, an input-pin, and an 
output pin. (The arrow points in the direction of the 
output.) If the gate input is zero, then output is set 
to high-impedance. If the gate input is set to one, 
then the value and strength of the input pin is passed 
to the output pin. 


The error-checking primitives do not model func- 
tionality. They are added to timing models of 
clocked components to check for setup and hold 
time violations and other clock-related errors. 
There are four timing checker primitives: 


e SETUP HOLD 

e SETUP RISE HOLD FALL 
e MIN PULSE WIDTH 

e EDGE TO EDGE 


The SETUP HOLD primitive has a clock and data in- 
put. For an active—-high clock, it generates an error 
message in the output listing when the data input is 
not stable from SETUP ns before the rising edge of 
the clock until HOLD ns after the clock is high. The 
SETUP HOLD primitive has two default body proper- 
ties attached: 


SETUP = 0.0 
HOLD = 0.0 


The properties SETUP and HOLD are assigned the 
required property values by using the GED change 
command. This primitive is used to check the set- 
up and hold times of registers and latches. 
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The SETUP HOLD primitive has an optional enable 
input that turns the checking on and off. If the en- 
able input is any value other than zero, then check- 
ing is enabled. If checking is enabled any time dur- 
ing the rising edge of the clock input, then checking 
is performed for that edge. 


SETUP RISE HOLD FALL | The SETUP RISE HOLD FALL primitive has a clock 
Primitive and data input. For an active-high clock, it gener- 
| ates an error message in the output listing when the 
data input is not stable from SETUP nanoseconds in 
the following circumstances: 


SETUPS, 2 
eae e Before the rising edge of the clock 
e While the clock is rising 
ie e While the clock is high 
SETUP=0. @ 
HOLD=2. @ e 


During the falling edge of the clock 


e Until HOLD nanoseconds after the clock has 
gone low 


The SETUP RISE HOLD FALL primitive has two de- 
fault body properties attached: 


SETUP = 0.0 
HOLD = 0.0 


The properties SETUP and HOLD are assigned the 
required property values by using the GED change 
command. This primitive is used to check the set- 
up and hold times of data being written into 
memories. 
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The primitive has an optional enable input that can 
be used to turn off checking. If the enable input is 
used, then any value other than zero causes check- 
ing to be enabled. If checking is enabled at any 
time between the rising edge and the falling edge, 
checking is performed for that clock pulse. 


MIN PULSE WIDTH The MIN PULSE WIDTH primitive has one data input. 
Primitive It checks that its data input has no pulses on it that 
are low for less than LOW ns, and no pulses on it 
that are high for less than HIGH ns. The MIN PULSE 


1B ae ; 
LOW=2. 8 WIDTH primitive has two default body properties 
HIGH=2. @ 
attached: 
LOW = 0.0 
HIGH = 0.0 
LOW=O, 2 
HIGH=0. @ The properties LOW and HIGH are assigned the re- 
quired property values by using the GED change 
command. 


The primitive has an optional enable input which 
turns checking on and off. If the enable input is any 
value other than zero, then checking is enabled. If 
checking is enabled any time during a given pulse, 
then the width of that pulse is checked. 
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EDGE TO EDGE Primitive 


1B 
MIN=0. @ 
MAX=0. @ 


1B 
MIN=0. @ 
MAX=0. @ 
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The EDGE TO EDGE primitive has two inputs, CK1 
and CK2. It checks that the beginning of a rising 
edge on CK2 is at least a minimum delay from the 
end of a rising edge on CK1 and that the end of a 
rising edge on CK2 is no more than a maximum de- 
lay from the beginning of a rising edge on CKi. The 
EDGE TO EDGE primitive has two default body prop- 
erties attached: 


MIN = 0.0 
MAX = 0.0 


Use the GED change command to assign values to 
the MIN and MAX properties. Only rising delays are 
used. 


The primitive has an optional enable input that turns 
checking on and off. If the enable input is any value 
other than zero, then checking is enabled. If check- 
ing is enabled any time during the rising edge of 
CKi, then checking is performed for that edge. If 
there is no edge on CK2 (that is, if CK2 does not 
change state), then no error message is generated. 
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Timing When creating timing models, you can size timing 
F bodies and add delay values to each primitive using 
Pr operties body and pin properties. Timing properties are: 
e DELAY e FALL 
e RISE e SIZE 


All Timing Verifier delay properties can be attached 
to a signal or a pin. The delay is applied at each 
input pin to which the wire with the delay property 
(or signal name containing the delay property) is at- 
tached. For designs where delays are related to 
changes in output loading, temperature, and voltage, 
the Delay Estimator can be used. 


Table 5-2 summarizes the timing properties. For 
detailed information on timing properties and direc- 
tives, refer to the ValidTIME Reference Manual. 


Table 5-2. Timing Properties 


Prop Controlling 
Name Directive (s) Comments 


DELAY DELAY_MODEL Specifies the delay time as a single value or the rise/fall 
RISE_FALL_MODELS | delay values as min, max, or min-max. DELAY MODEL 


directive selects which value to use for current timing 
run; min-max is the default. 
DELAY_MODEL 
RISE_FALL_MODELS 
FALL DELAY_MODEL 
RISE_FALL_MODELS 
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Assigns RISE delay to a timing primitive. The directives 
DELAY_MODEL and RISE_FALL_MODELS select delay 
values. 


Assigns FALL delay to a timing primitive. The directives 
DELAY_MODEL and RISE_FALL_MODELS select delay 
values. 


Specifies the number of bits on a pin. Can also use 
SIZE=SIZE to match primitive size to the SIZE property 
attached to the body drawing. 


Timing Model 


The DELAY Property 


The RISE Property 
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Delays are given in nanoseconds. Primitives without 
an explicit DELAY are assumed to have a delay of 
zero. By convention, primitives are given delays to 
model the worst-case behavior of the part being 
modeled, but this is not required. The syntax of the 
DELAY property in timing models is: 


DELAY=min 
DELAY=max 
DELAY=min-max 


The Timing Verifier’s DELAY_MODEL directive se- 
lects which value (min, typ, or max) to use for cur- 
rent timing run. Min tells the Timing Verifier to use 
only minimum delays. Max tells the Timing Verifier 
to use only maximum delays. Min-max is the de- 
fault. It tells the Timing Verifier to use both the 
minimum and maximum available delays. 


For the timing to function correctly, it is only neces- 
sary to define one possible timing behavior of the 
part (min or max). Exercise care when specifying 
delay values for parts; in particular, zero-delay 
parts can result in unexpected behavior in a circuit. 


Rise delays are specified using the RISE property 
with a rise delay time value. The Timing Verifier’s 
DELAY_MODEL and RISE_FALL_MODELS directives 
are used to select delay values. 
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The FALL Property 


The SIZE Property 
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Fall delays are specified using the FALL property 
with a rise delay time value. The Timing Verifier’s 
DELAY_MODEL and RISE_FALL_MODELS directives 
are used to select delay values. 


Most timing primitives can have a SIZE property to 
specify the number of bits on a pin. A primitive can 
be given the property SIZE=SIZE, which means that 
the size of the primitive is taken from the SIZE prop- 
erty attached to the part being modeled. 


Many primitives have inputs and outputs that are not 
affected by the SIZE property. All enable inputs, 
clock inputs, and chip select inputs have a fixed 
width of one bit. The select input of an eight-bit 
multiplexer is always three bits wide. 
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Modifying Timing 
Models 
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Timing models are carefully designed to correctly 
model the part while including no extraneous data. 
The smaller the model, the faster the Timing Veri- 
fier can run. Models are therefore difficult to intui- 
tively grasp; make as few changes to models as ab- 
solutely necessary. The most frequent change to a 
timing model is the change of the value of a delay 
property. Use the change command in GED to 
change the value. Be careful to change the correct 
instance of the delay property in the model. To ac- 
commodate different delay paths through the device, 
propagation delays are usually divided up and 
placed in different locations in the model. Examine 
the model carefully to choose which delays you need 
to change. 
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Creating Support 
Components 


This section discusses creating and using the following 


support components: 


e Connector 
e Resistor pack 


e Ground 


Support Components 


Creating A 
Connector 


PIN_NAME=CON_PINCSIZE-1. . 2>\NAC 


There are many sizes of connectors you might re- 
quire to complete a design. Rather than creating 
each size connector, you can create a generic “pin” 
connector that you can use to design any size 
connector. 


Follow this procedure to create a generic connector: 


1 Access GED and edit a new body drawing: 


edit conn128.body.1.1 


split the body name (note) away from the 
body origin and delete the body name. 


Use the wire command to create a single pin 
shape (Fe). Center the pin on the origin. 


Use the dot command to add a connection 
point to the pin (Fe). 


Use the signame command to attach the pin 
name: 
CON_PIN<SIZE-1..0>\NAC 


The \NAC (no assertion check) property tells 
the compiler that both high-asserted and 
low-asserted signals can be attached to the 
pin. Place the pin name close to the pin. 


Attach the $PN (pin number) property to the 
pin and give the property the value “?” (ques- 
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tion mark). Place the property to the left of 
the pin, display it right-justified (so text ex- 
pands to the left and does not overwrite the 
pin), and display only the property value (?). 


7 Attach the following properties to the body 
origin: 
LOCATION=? 
PATH=? 


Place the LOCATION property immediately 
above the pin, display it left-justified, and 
display only the property value. Place the 
PATH property to the left of the pin, display it 
right-justified, and make it invisible. 


The conn128 connector is shown in Figure 6-1. The 
top drawing shows all the attached properties, and 
the bottom drawing shows how the conn128.body 
drawing should actually appear. 


| LOCATION=? 
PATH=? $PN=? Jae 


PIN -NAME=CON_PIN<SIZE-1. . @>\NAC 


2 
2 | 
CON_PIN< SIZE-1. .@>\NAC 


Figure 6-1. Body Drawing for CONN128 Connector 
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Tips on Attaching ~ Attaching the LOCATION, PATH, and $PN prop- 
Connector Properties erties during component creation allows you to 
define their default positions on a drawing. 


~ Making the LOCATION property a hard prop- 
erty (not starting with a $) encourages the 
user to assign a value to the property before 
the schematic can be written. 


~ Attaching the $PN property as a soft property 
allows the system to assign the pin number 
but locates the number where you want it. 


Creating a Second You can create a second version of the conn128 con- 
Version of the nector where the pin extends to the left of the origin 
Connector (an output connector). The properties are the same 


as the original version, but their placement is differ- 
ent. Make the following changes to the attached 
properties: 


e Move the PATH and $PN properties to the 
right of the pin. Make sure the $PN property 
has enough space to print up to a three-digit 
pin number. 


e Make the PATH property display left-justified 
and the LOCATION property display right- 
justified. (The $PN property remains right- 
justified.) 
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Version 2 of the conn128 connector is shown in 
Figure 6-2. The top drawing shows all the attached 
properties, and the bottom drawing shows how the 
conn128.body drawing should actually appear. 


ee | SPN=? PATH=? 
PIN _NAME=CON_PIN<SIZE-1..@>\NAC - 7 


? | 
CON_-PIN<SIZE-1. . @>\NAC 


Figure 6-2. Body Drawing for Version 2 of the CONN128 Connector 


The .PART Drawing To define the connector as a lowest-level compo- 
nent, create a .PART drawing that contains a 
DRAWING body with the TITLE and ABBREV proper- 
ties attached. The .PART drawing for the conn128 
connector is shown in Figure 6-3. 


DRAWING 
TITLE=CONNL28 


ABBREV=128-PIN_CON 
LAST_MODIFIED=Fri Sep 15 11:14:20 1989 


Figure 6-3. Part Drawing for CONN128 Connector 
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The Physical Model Next, create the physical model of the conn128 con- 
nector by adding physical information to a library 
drawing. Follow these steps: 


1 Create a library drawing and add the conn128 
connector body: 


edit conn library.logic 
add conni28.. body | 


2 Attach the PIN NUMBER property. Use the 
compact pin number syntax discussed in Sec- 
tion 3 to enter the pin numbers: 


PIN _NUMBER=<128..1> 


3 Add a DRAWING body and attach the TITLE 
and ABBREV properties. 


4 Verify property attachments, check and write 
the drawing. 


Note: When you check and write the conn library drawing, 
you get the following error message: 


"LOCATION" property is only a placeholder 
...done checking 

CHECK detected problems with this drawing. 

Type ; to write anyway or anything else to abort 


Enter a semicolon to write the drawing anyway. The 
LOCATION property will be defined when the con- 
nector is added to a drawing. 


The conn library drawing now looks like the one in 
Figure 6-4. 
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— PIN_NUMBER=< 128. .1> 


DRAWING 


TITLE=CONN LIBRARY 
ABBREV=CONLIB 
LAST_MODIFIED=Fri Sep 15 17:28:48 1989 


Figure 6-4. Conn Library Drawing for the CONN128 Component 


Once you enter all the physical information into the 
library drawing, follow these steps to complete the 
physical model: 


1 Edit the compiler.cmd file, change the 
ROOT_DRAWING to conn library, redirect 
OUTPUT from logic to chips, and make sure 
the correct .wrk file is specified. 


2 Compile the library drawing to create the 
chips.dat file. 


3 After the drawing compiles successfully, 
change the name chips.dat to chips_prt and 
move the physical model to the correct com- 
ponent subdirectory: 


mv chips.dat conn128/chips_ prt 


The chips_ prt file for the conn128 connector looks 
similar to the one shown in Figure 6-S. 
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FILE TYPE=LIBRARY_PARTS; 
TIME=’COMPILATION ON FRI SEP 15 18:48:34 1989’; 
primitive ’“CONN128°: 
pin 
“CON _PIN’<0O>; 
PIN NUMBER=’ (128..1)°; 
end_pin; 
body 
BODY_NAME=° CONN128° ; 


(The body properties differ 

from file to file depending 

on the physical requirements 
- of a component.) 


end_body; 
end_primitive; 
END. 


Figure 6-5. CONN128 Chips_prt File 


Creating Additional Once you create the body drawing for the generic 

Physical Models connector pin, you can create other components us- 
ing the same body drawing. For each new compo- 
nent you want to create, you need to: 


e Copy the body drawing 
e Create a new part drawing 
e Edit the library drawing 
e Compile the component 


Follow these steps to use the connI28 connector to 
create a connector called din3_32, a 96-pin connec- 
tor that has three rows of 32 pins each. 
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1 Edit the conn128.body drawing and use the 
diagram command to rename the drawing: 


edit conn128.body 


You can copy both versions diagram din3_32.body 
of the conn128 to make 
both versions of the 2 write the new drawing to save it. 


din3_32 if necessary. 


3 Create a .PART drawing for the new 
component. 


4 Edit the conn library drawing and use the 
change command to alter the PIN NUMBER 
property: 


pin_number=<C32..C1,B32..B1,A32..Al1> 


5 Check and write the drawing. You still get 
the error message about the LOCATION prop- 
erty. Enter a semicolon to write the drawing 
anyway. The LOCATION property will be de- 
fined when the connector is added to a 
drawing. 


6 Compile the library drawing (output chips) to 
create the chips.dat file. 


7 After the drawing compiles successfully, 
change the name chips.dat to chips_ prt and 
move the physical model to the correct com- 


ponent subdirectory: 
The system name for the 
din3_32 connector does not 
contain an underscore. 


mv chips.dat din332/chips prt 
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The chips_ prt file for the din3_32 connector should 
look similar to the one shown in Figure 6-6. 


FILE _TYPE=LIBRARY_PARTS; 
TIME=°COMPILATION ON MON SEP 18 08:55:14 1989’; 
primitive “DIN3 32’; 
pin 
“CON_PIN’ <O>: 
PIN NUMBER=° (C32. .C1,B32..B1,A32 
end _ pin; 
body 
BODY_NAME=‘DIN3_ 32’; 


end_body; 
end_primitive; 
END. 


Figure 6-6. DIN3_32 Chips_prt File 
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Creating a 
Connector Break 


Since the connector 
break is a comment- 
body, it does not need 
a .PART drawing and 
it is not compiled. 
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You can use the conn128 body to create connectors 
ranging from one pin to 128 pins. When you create 
a small connector, it is simple to show the whole 
connector in one place on a schematic. But if you 
create a large connector, it may not be necessary or 
even possible to show all the pins in the same loca- 
tion on a schematic. A simple comment-body 
called a connector break indicates that the connector 
shown is only a portion of the complete connector. 
Follow these steps to create a connector break body: 


1 Edit a body drawing called conbrk and delete 
the body name (note). 


2 Use the wire command to create the follow- 
ing shape: 


Center the shape around the body origin. 


3 Use the dot command to add connection 
points to the ends of the wires: 


oro 


4 Use the signame command to attach an NC 
signal name to each end (since the pin can be 
left unconnected): 


NC. /\ NC 


5 Attach the property COMMENT_BODY=TRUE 
to the body origin and make the property 
invisible. 
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Using the Connector To create connector packages on a logic drawing, 

and Connector you add as many connector pins and connector 

Break Bodies breaks as you need. For example, you might need 
to show eight pins of a 128-pin connector in one 
place on a logic drawing. Follow these steps to cre- 
ate the necessary connector on a schematic: 


1 Edit your logic drawing and add a connector 
pin: 
edit test 
add conn128 


2 Use the change command to assign a value 
to the LOCATION property, then make the 
property invisible. 


3 Select the copy command and copy the con- 
nector pin seven times. Place the copies be- 
low the original pin. 


You can also 
add a conbrk 
One OBES G 4 Add a conbrk body and place it slightly below 
connector body. j } 

the connector pins (so that it is not over- 


written by any pin numbers). 


"TTTTTTTT F 


5 Use the wire command to complete the con- 
nector shape. Start the wire at one end of the 
connector break and place it over the connec- 
tors to connect them. Use the signame com- 
mand to attach the same signal name as you 
assigned to the LOCATION property. 


6 Use the section command to assign pin num- 
bers to each connector pin. 
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Figure 6-7 shows several versions of the connector 
created using both versions of the connI28 and 
din3_32 bodies. 


conn128 connectors din3_32 connectors 


Figure 6-7. Connector Examples 
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Simulation and 
Timing Models 


The simulation information 
is provided in Section 4 
and the timing information 
is provided in Section 5. 


Create a simulation or timing model of the conn128 
body to emulate the behavior and operation of the 
connector. The .SIM and .TIME models for the con- 
nector are identical. Both models are synonymed 
(with the synonym body from the Standard library) 
to the signal name NC because the connector is the 
logical completion of the circuit. 


Figure 6-8 shows the simulation or timing model 
for the connI28 connector. 


PIN NAMES 
CON_PIN<SIZE-1. . @>\NACNI 


CON _PIN<SIZE-1. . @>\NAC\T SIG_NAME=NC 


Figure 6-8. Simulation or Timing Model for the CONN128 Connector 
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Creating A You can create a sizeable resistor that you can use 
a alone or that you can group to create a standard re- 
Resistor Pack sistor pack. Use GED to create the resistor body 
res5 sip6.body.1.1 (5 resistor, 6-pin, single in-line 
package) shown in Figure 6-9. Use the property 
command to add the property VALUE=? and display 

only the property value. 


COMMON NNAC i AA <SIZE-1..@> NNAC 


Figure 6-9. Version 1 of the RESS5 SIP6 Resistor 


This standard resistor pack includes five resistors 
with one common pin. Create the resistor pack as 
the second version of the original resistor. The 
res5 sip6.body.2.1 is shown in Figure 6-10. Attach 
the VALUE property to the origin and display only 
the property value. Attach the HAS FIXED SIZE=5B 


property to the body origin and make the property 
invisible. 


COMMON N\NAC 


Figure 6-10. Version 2 of the RESS SIP6 Resistor 
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The .PART Drawing To define the resistor as a lowest-level component, 
create a .PART drawing which contains a DRAWING 
body with the TITLE and ABBREV properties 
attached. The .PART drawing for the res5 sip6 resis- 
tor is shown in Figure 6-11. _ 


DRAWING 


TITLE=RESS _SIP6 
ABBREV=RS556 


PART NAME=RESSSIP6 
LAST_MODIFIED=Sun Oct 1 16:54:38 1989 


Figure 6-11. Part Drawing for RES5 SIP6 Resistor 


The Physical Model Create the physical model of the res5 sip6 resistor by 
adding physical information to a library drawing. 
The drawing should look like the one shown in 
Figure 6-12. 


PATH=iP 
PART —NAME=RESSSIP6 
UNKNOWN _LOADING=T RUE 
ALLOW_CONNECT=TRUE 
PHYS—DES_PREF IX=Z 


PIN-NUMBER=¢1;1;1,;1;1> ? 


PIN NUMBER=¢6:; Ss 45 33 2> 


DRAWING: 


TITLE=RES LIB 
ABBREV=RESS 
LAST-MODIFIED=Mon Oct 2 15:08:35 1989 


Figure 6-12. Library Drawing for the RES5 SIP6 Resistor 
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Note: When you check and write the res lib drawing, you 
get the following error message: 


"VALUE" property is only a placeholder 
...done checking 

CHECK detected problems with this drawing. 
Type ; to write anyway or anything else to abort: 


Enter a semicolon to write the drawing anyway. 
You define the VALUE property when the resistor is 
added to a drawing. 


After you enter all the physical information into the 
library drawing, compile the library drawing (with 
output chips) and move the chips.dat to the 
chips_ prt file in the resSsip6 subdirectory. 


Physical Part Tables You can use physical part tables to create different 
types (versions) of resistors using res sip6 resistor 
body. Resistor versions can vary in resistance value, 
power dissipation, cost, or tolerance. For informa- 
tion on creating and using physical part tables, refer 
to the ValidPACKAGER Reference Manual. 


Simulation and The .SIM and .TIME models for the res5 sip6 resistor 
Timing Models are identical. Figure 6-13 shows the simulation or 
timing model for the res5 sip6 resistor. 


*% <SIZE~1..@> NI 


Figure 6-13. .SIM or .TIME Drawing for the RESS5 SIP6 Resistor 
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Creating A 
Ground 


You can create a ground (logic 0) body to use as a 
permanent enable input. Use GED to create the 
symbol shown in_ Figure 6-14. Use the 
display heavy command to change the thickness of 
the horizontal lines. 


G KSIZE 1s «Oy NINAC 


Figure 6-14. BODY Drawing for the GND Ground 


The .LOGIC Drawing 


Making the ground body sizeable allows you to at- 
tach the ground to a sizeable component (for exam- 
ple, a pull-down through a sized resistor on a bus) 
without having to replicate the ground each time. 
You can ignore the size capabilities of the ground if 
you do not need a sizeable ground, since SIZE=1B is 
the default value of the SIZE property. 


Because the ground body is not an actual physical 
body, there is no .PART drawing defined for the 
component. The ground body requires a .LOGIC 
drawing to allow the Packager to resolve the ground 
body into a net name. 


10/1/89 


Support Components 


Figure 6-15 shows the .LOGIC drawing for the gnd 
component. The pin name for the ground is 
synonymed to gnd so that the entire ground net in a 

For more information schematic is synonymed to the same name. The 

on the replicate pa- \R SIZE parameter replicates the ground to the size 

rameter: (“R), reser £0 specified by the SIZE property attached to the body 
the SCALD Language gay : : 

Reterence: Manual: when it is added to a logic drawing. The \G global 
parameter forces the entire net to have the same net 
name when a schematic that includes the gnd body is 
compiled. 


G <SIZE-1..0> NI GND \R SIZE \G 


1P 


Figure 6-15. LOGIC Drawing for the GND Component 


Simulation and Figure 6-16 shows the .SIM or .TIME model for the 

Timing Models gnd body. The pin name for the ground is 
synonymed to zero because the ground in a logic 
design is typically zero. The \R SIZE parameter rep- 
licates the ground to the specified size when it is 
added to a logic drawing. There is no \G global 
parameter attached since constants are global by 
nature. 


G_ <SIZE—-1..@> NI 0 \R SIZE 


Figure 6-16. Ground .SIM or .TIME Drawing 
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This section discusses: 
e Creation checklist 


e Testing issues 


Testing the Library 


Creation The following cael summarizes ae quire 

: points to remember when creating models. prob- 

Checklist lems arise, check these areas to make sure the new 
information meets the desired standards. 


~ Are all the library files owned by the 
librarian? 


~ Do the model shape and the signal names 
used on the model correspond to your corpo- 
rate conventions? 


~ Do the signal names follow the correct Valid 
Library Format? 


~ Do the signal names follow the correct bit 
ordering? 


~ If you are having problems accessing the li- 
brary where the model resides, is the library 
listed in the master.lib file? 


~ Are you using a test directory instead of the 
final directory to develop models for each 
part (and avoiding problems with a produc- 
tion directory)? 


~ Are new components approximately the same 
size and shape as other library components 
so they integrate well with other components 
on the schematic? 


~ Is your component centered around the body 
origin? 
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Are high-asserted pins drawn with a 
0.1-inch wire and low-asserted pins with a 
0.1-inch bubble (circle)? 


Are clock pins marked with a clock wedge if 
required? 


Did you use bus-through pins whenever 
possible? Are their pin names the same as 
the visible pin to which they are connected? 


Do low-asserted pin names end with the cor- 
rect low-assertion character (an asterisk in 
Library Format 1)? 


Are all properties correctly attached? 


Are the \NAC and \NWC properties attached 
to pins on bodies when necessary? 


Does the body contain notes detailing each 
pin name and the purpose of the body? 


If it is not a sizeable component, is the 
NEEDS _NO_SIZE property attached to the 
body? 


If it is the flat representation of a sizeable 
component, is the HAS_FIXED_ SIZE property 
attached to the body? 


Are pins assigned to bubble groups when 
appropriate? | 


Are pins that should start in the bubbled state 
defined with the BUBBLED property? 


7-3 


Testing the Library 


Have you created all the required versions of 
a body? 


If you used the smash or diagram commands 
to create a new component, did you also copy 
and change the .PART, .SIM, and .TIME draw- 
ings if necessary? 


Did you create a .PART drawing for the new 
component? 


Do asymmetrical components have one of 
each section represented in the library 
drawing? 


Are bodies that have no logical function 
“commented out” with the property 
COMMENT_BODY=TRUE or the _ property 
BODY_TYPE=COMMENT? 


Does each pin of each component have a 
PIN_NUMBER property attached (except bus- 
through pins)? 


Do different sections of asymmetrical compo- 
nents have different pin names? 


Do all pins have an INPUT_LOAD or 
OUTPUT_LOAD property (or both)? 


Did you convert the INPUT_LOAD or 
OUTPUT_LOAD to the required measurement 
(typically milliamps) if the data book used a 
different unit of measurement? 


Are swappable pins assigned to the same pin 
group? 
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Is the OUTPUT_TYPE property attached to the 
output pins of open-collector, open-emitter, 
and tri-state components? 


Are any necessary load-checking properties 
attached to the library drawing? 


Did you rename the chips.dat file to chips_ prt 
and move it to the correct subdirectory? 


Are all the nets on the simulation model 
named so that there are no ambiguous error 
messages due to unnamed signals? 


Did you make sure GED can access the re- 
quired libraries (such as Sim and Time)? 


Do all the interface signals in the simulation 
and timing models include the \I interface 
property in the signal name? 


Do all interface signals that require an ex- 
plicit width have the width specified? 


Do the simulation and timing models have 
the correct body and pin delay properties? 


If pin delay properties are used in the simula- 
tor model, is the PIN_DELAY directive set to 
ON in the simulator.cmd file? Is_ the 
RISE_FALL directive ON if the PRISE and 
PFALL properties are to override the PDELAY 
property? 


Are all delays calculated in nanoseconds? 
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~“ Is the DELAY MODE directive in the 
simulator.cmd file set to the correct value 
(min, typ, max)? 


~ Did you check for zero-delay parts in the 
simulation and timing models to eliminate 
unexpected behavior in the circuit? 


~ Did you add the PIN NAMES component to the 
timing model to check that all the pins are 
accounted for (and spelled correctly)? 
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Testing Issues There is no one program that tests all aspects of a 
component. The main issue is to test the component 


for accuracy throughout the various design tools you 
use for your components. 


The minimum testing of a new component should 
include compiling the bodies and the models. Any 
syntax errors are discovered during compilation and 
can be corrected. Complex parts may take a long 
time to verify; be sure to budget enough library de- 
velopment time for testing. 


~ If you have more than one component to test, 
you can create an EXAMPLE OF EACH 
LIBRARY PART drawing and use it for testing, 
since when you compile that drawing, it in- 
vokes all versions of all parts. 


~ Make sure you can add all versions of a new 
component. 


~ Try the bubble command on appropriate pins 
to make sure they are defined with a bubble- 
able pin and they are in the correct bubble 
group, if any. 


~ Attach a wire to each connection point to be 
sure that the wire attaches to the correct 
location. 


~ Wire bus-through pins to check that they con- 
nect correctly. 


~ For sizeable components, first set the SIZE 
parameter to 1 (the default) and then to some 


10/1/89 1-7 


Testing the Library 


other value to test the vector part 
implementation. 


Exercise timing models to make sure that the 
model behaves correctly and that the DELAY, 
RISE, and FALL property values have been 
correctly assigned. 


If a directive or property has more than one 
possible value, test the model using the entire 
range of values. 


Generate errors in setup and pulse width to 
make sure that the signals reported by the 
Timing Verifier have names that are easily 
understood without looking at the model; all 
errors should be reported in terms of the pins 
of the part. 


Use the TIMES property to verify drive and 
load capabilities. Try overloading the con- 
nections and checking the resulting error 
messages from the Packager to be sure all 
loading violations are detected. 


Use the section command to make sure the 
component sections correctly. 


Use the pinswap command to make sure the 
pin groups have been defined properly. 
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Adding Physical 
Information (UNIX Only) 


This section discusses: 
e Using phys_dat to add physical information 
e Phys_dat file syntax 


e Pin number formats for the phys_dat file 


Text File Method of Adding Physical Information 


Using Phys_dat 
to Add Physical 
Information 


The chips.dat file is only 
a template at this point. 


On the UNIX operating system, you can use a text 
file method to specify the physical information for a 
library component. The text file is called the 
phys_dat file, and the method is similar to the library 
drawing method except that the pin and body prop- 
erties are entered into a text file rather than directly 
onto a drawing. This method may prove faster, es- 
pecially with reference elements with a large number 
of pins. Once the property information is entered 
into the text file, the chips.dat file is automatically 
updated with the information from the file by run- 
ning the addphysinfo script. Follow these steps to 
create a chips_ prt file using the phys _dat file: 


1 Access GED and edit a library drawing. 


2 Add the sizeable version (Version 1) of the 
component to be compiled. 


3 Add a DRAWING body and attach the TITLE 
and ABBREV properties. 


4 write the drawing to save it. 


5 Edit the compiler.cmd file and change the 
ROOT_DRAWING directive to the correct 
library name. Make sure the correct .wrk file 
is specified. 


6 Compile the library drawing (output chips) to 
create the chips.dat file. 


7 Move to the component subdirectory and use 
the system text editor to create a new file 
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called phys dat. The file requires the same 
information as described in Section 3, The 
Physical Model: 


e Part name 
e Family 
e Power and ground pin assignments 
e Pin name 
e Pin number(s) 
e Output type 
e Input/output load 
e Bidirectional pins 
The information must be entered in the order 


shown above. Figure A-1 shows a phys_dat 
file for the TTL 293 component. 


PART 74293 

FAMILY TTL 

POWER_PINS (VCC:14;GND:7) 
PINS 

Q<3> (8) OUTPUT 
Q<2> (4) OUTPUT 
Q<1> (5) OUTPUT 


Q<0> (9) OUTPUT 
CLKA* (10) INPUT 
CLKB* (11) INPUT 
CL1 (12) INPUT 
CL2 (13) INPUT 
END 


Figure A-1. Phys_dat File for the TTL 293 Component 
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8 Move up one directory level and execute the 
addphysinfo script on the chips.dat file: 


cd .. 
addphysinfo chips.dat 


The addphysinfo script automatically updates 
the chips.dat file to include the information in 
the phys_dat file. The script creates several 
files that all begin with the prefix Jib. For 
example, the /iblst.dat file contains a sum- 
mary of execution. After an error-free run 
of the script, these files can be deleted. 


9 Change the name chips.dat to chips_ prt and 
move the physical model to the correct com- 
ponent subdirectory: 


mv chips.dat 293/chips_prt 
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Phys dat Syntax The phys_dat file specifies the same information as 


the library drawing but uses a different entry format. 
A pin entry in the phys dat file has the following 
syntax: 


pin (pin_id) output_type (load) [(/oad)] [bidir] 


Separate the values in the pin entries with spaces or 
tabs. 


pin The pin name that was assigned in the body draw- 
ing. Pin name entries can be scalar or vector. 


pin_id Any combination of alphanumeric characters and/or 
the underscore character that defines the pin 
number. Pin numbers can be scalar or vector, sin- 
gle or multiple section, or asymmetrical. The pin 
number formats are described beginning on page 
A-6. 


output_type Defines whether the pin is an input pin, output pin, 
open collector pin, or tri-state pin. 


load The input/output loading value of the pin. If the pin 
is a tri-state, there are two sets of load values to 
define both the input load and the output load. 


bidir Specifies a pin that is both an input pin and an out- 
put pin. 


Section 2, Component Creation, contains more infor- 
mation on pin names. Section 3, The Physical Model, 
contains details on pin numbers, output types, load- 
ing values, and the bidirectional property. 
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Pin Number The pin number formats described in Section 3 can 
also be defined in the phy_dat file: 
Formats : 
e Single section scalar pin 
e Single section vector pin 
e Multiple section scalar pin 
e Multiple section common pin 
e Multiple section common vector pin 
e Asymmetrical components 


Single Section In single section scalar format, you enter each pin 

Scalar Pins and its associated pin number individually in the 
phys_dat file. The phys_dat file for the TTL 293 com- 
ponent contains examples of single section scalar 
pin entries: 


CL1i CL2 


x 
CLKBk@]>B 
CLKAX @ >A 
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Single Section Single section vector pins can be entered individu- 

Vector Pins ally (like those of the TTL 293) or in a vector for- 
mat. The Q pins of the TTL 293 can be shown in 
vector format: 


(8,4,5,9) 

(10) 

(11) 

(12) 

(13) 
Multiple Section Each pin of a multiple section is defined by a list of 
Scalar Pins pin numbers, one pin number for each section in the 


part. The pin numbers for each section are sepa- 
rated by commas. Pins for the first section are in 
the last position in the phys_dat file, pins for the sec- 
ond section are in the second-last position, and so 
on. 


The LS00 component is an example of a sizeable 
component with multiple section scalar pins. If the 
component is given the property SIZE=4B, each logi- 
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cal pin of the component has four pin numbers, one 
for each section: 


A <SIZE-1..@> 


(> 
x @ 
20 
ag Ne Y <SIZE—-1.. @>* 


B <SIZE-1..@> 


(1,4,9,12) INPUT (-0.4,0.02) 
(2,5,10,13) INPUT (-0.4,0.02) 
(3,6,8,11) OUTPUT (8.0,-0.4) 


Multiple Section The LS374 octal register is an example of a compo- 

Commen Pins nent that has multiple sections with common pins. 
The pin numbers for multiple sections appear more 
than once in the file entry. Pins for the first section 
of the part appear in the last position in the phys dat 
file, pins for the second section are in the second- 
last position, and so on. 


D<SIZe-1..0>—pn a} Q<SIZE-1..@> 


LS374 
CLK —p 


Oe 


e 
ENABLE 


D<O> (3,4,7,8,13,14,17,18) 

OE* (1,1;1,1,1;1,1,2) 

CLOCK (11,11,11,11,11,11,11,11) 

Q<0> (2,5,6,9,12,15,16,19) (24.0,-2.6) 
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The clock and enable pins are common to all eight 
flip-flops in the package. The D and Q pins are 
defined so that one bit is assigned to each flip-flop. 


Pins that are common only to certain sections of a 
component are represented in the same manner as 
pins that are common to all sections, except that 
these pin numbers are present only in the sections 
for which they are common. The LS367 component 
is an example of a component with multiple—section 
common pins: 


BUBBLE_GROUP=¢AiY> 


A<0> (2,4,6,10,12,14) 
OE* (1,1,1,1,15,15) 
Y<0> (3,5,7,9,11,13) (24.0,-2.6) 


The pin numbers for the open emitter pin show that 
one output enable pin is common to four sections of 
the component, and one output enable pin is com- 
mon to the other two sections of the component. 
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Multiple Section If a multiple-section component has vectored pins, 
Common Vector each pin number and section are separated by com- 
Pins mas. The pin numbers enclosed in angle brackets 


specify individual bits of the pin, not different sec- 
tions for the pin. 


An LS189 16-word by 4-bit RAM is an example of a 
component having vector pins and multiple sections. 


BUBBLED=¢Q> 
BUBBLE_GROUP=¢D:Q) 
CS%* WE>k 


D <SIZE-1..@ « » Q <SIZE-1. .0>* 
AD <3..@> 


ae 
CS* WE>k 


D<O> (4,6,10,12) INPUT 
AD<3..0> (<15,14,13,1>,<15,14,13,1>,<15,14,13,1>,<15,14,13,1>) INPUT 


WE* (3,3,3,3) INPUT 
CS* (2,2,2,2) INPUT 
Q<0>* (5,7,9,11) TS 
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Asymmetrical Components with multiple sections that are function- 

Components ally different, such as the LS241 bus transceiver, 
need one version of the body defined for each type 
of section in the component. To identify which pins 
are present in a given section, the pins of the differ- 
ent versions must have different pin names. 


Even though some pins may not be present in a sec- 
tion, the phys _dat file specifies all the sections of the 
component. Any pin that is not present in a given 
section is specified with a pin number of zero. 


BUBBLE_GROUP=¢A: Br 
YQ <SIZE-1..@> 


Yl <SIZE-1..@> 


(17,15,13,11,0,0,0,0) .2,0.02) 
(19,19,19,19,0,0,0,0) .2,0.02) 
(3,5,7,9,0,0,0,0) .02,0.02) (24.0,-15.0) 
(0,0,0,0,2,4,6, 8) .2,0.02) 
(0,0,0,0,1,1,1,1) .2,0.02) 
(0,0,0,0,18,16,14,12) .02,0.02) (24.0,-15.0) 
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Library Drawing 
Method 


The current library drawing method of creating the 


physical model of a component differs from the previ- 


ous method. This section discusses: 


e The previous method versus the current 
method 


e Why the change occurred 


Changes in the Library Drawing Method 


Previous versus 
Current Method 


Creating a library drawing used to require changing 
the entire library. Modifications in the Valid design 
tools make it more reasonable to create and main- 
tain the physical model for one component at a time. 


Creating a library drawing for one component at a 
time means that there is no need to use the 
makechipstfiles utility to separate the .prt file into 
separate chips_ prt files. You can simply rename the 
chips.dat file to chips_ prt and move it to the correct 
subdirectory. 


Table B-1 shows the differences between the previ- 
ous method of creating a library drawing and the 
current method. 
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Table B-1. Previous and Current Library Drawing Methods 


PREVIOUS METHOD CURRENT METHOD 
1 Create a library drawing. 1 Create a library drawing. 


2 Add the sizeable or vectored 2 Add the sizeable or vectored 
version of each component in version of one component to 
the library to the drawing. the drawing. 


3 Attach the body properties. 3 Attach the body properties. | 
4 Attach the pin properties. 4 Attach the pin properties. 


5 Verify property attachments, 5 Verify property attachments, 
check and write the drawing. check and write the drawing. 

6 Edit the compiler.cmd file. 6 Edit the compiler.cmd file. 

7 Compile the library drawing. 7 Compile the library drawing. 


8 Move the chips.dat file to a file 8 Move the chips.dat file to the in- 
with the same name as the library dividual component directory and 
and a .prt extension (for example, rename it chips_ prt. 
Isttl.prt or newparts.prt). 


9 Run the makechipstfiles utility on 
the .prt file to create the individ- 
ual chips files (chips_ prt files). 
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Reasons for the 
Change 


The .prt file is no 
longer necessary. 


Modifying the entire 
library is not 
required. 


B-4 


There are three reasons why the method of creating 
the physical model changed. 


GED originally did not accept pin numbers on a com- 
ponent until the component. was first compiled, 
packaged, and back annotated. When the section 
command was created, the system accepted pin 
numbers during schematic entry, but the command 
could not read the .prt file directly, so the physical 
information for the component was placed in a new 
file called chips_prt. This file was located in the 
component subdirectory along with the rest of the 
component files. Since the chips_prt file was new, 
the Packager still read the .prt file for physical infor- 
mation, and the section and pinswap commands 
read the chips_prt file. Now the Packager has the 
ability to retrieve information from the chips_ prt 
file, so the .prt file is no longer required. 


The original method of creating a library drawing 
required updating the entire library each time you 
created or modified a library component. When a 
library drawing contains only the component that is 
being modified, you save time and effort creating 
the library drawing. Also, any manual changes you 
made to the physical information files for the other 
components in the library are not overwritten when 
you recompile the library. 
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Physical information Asymmetrical components have always required that 
for asymmetrical you manually modify the chips_ prt file to include 
components does the physical information for all the sections of the 
not get overwritten component. When you update a single component 
: instead of the entire library, you do not overwrite the 
manual changes to the chips_ prt file for asymmetri- 
cal components, and you do not have to re-enter the 

changes by hand. 
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Symbols 


| (pipe character), 2-17 


A 


ABBREV property, 3-2 to 3-3 
abbreviations, truth table, 4-10, 5-7 
accessing libraries, 1-9 to 1-10 
ADDER primitive, 4-30 


adding 
body properties, 3-7 to 3-10 
bubbled pins, 2-15 
physical information, 3-5 to 3-31 
using phys_dat file, A-2 to A-4 
pin 
names, 2-16 
properties, 2-17, 3-22 to 3-28 
pins, 2-11 


addphysinfo script, A-2 to A-4 
ALLOW_CONNECT property, 3-28 
ALU primitive, 4-31 

AND primitive, 4-11, 5-8 
annotating bodies, 2-19 to 2-20 


annotation standards, 2-20 
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Index 


index 


arc command, 2-11 
archiving library drawings, 3-31 
arithmetic primitives, 4-30 to 4-32 


assertion 
checking, 2-18 
pin, 2-15 
assigning 
internal part numbers, 3-10 
pin numbers, 3-11 to 3-21 


asymmetrical 
bubble groups, 2-28 to 2-29 
components, 3-6 
pin 
names, 1-15 to 1-16 
numbers, 3-19 to 3-28, A-11 


attaching properties, 6-4 
to components, 3-2 


attachments, checking, 2-17 


bidirectional pins, placing, 2-13 
BIDIRECTIONAL property, 3-25 
binary files, 1-13 
bit subscript, 2-16 


Index 


bodies 

adding physical information, 3-5 to 
3-31 

annotating, 2-19 to 2-20 

creating multiple physical models, 
6-8 to 6-10 

DRAWING, 3-2 

wiring together, 2-13 


body 

delays, 4-41 

grid settings, 2-7 

names, 2-8, 2-20 

origin, 2-8 

properties, 2-21 to 2-30 
adding, 3-7 to 3-10 
BODY_TYPE, 3-10 
COST, 3-10 
FAMILY, 3-8 
POWER_PINS, 3-9 
PART_NUMBER, 3-10 
PHYS_DES_PREFIX, 3-10 
simulation, 4-41 to 4-42 

shapes 
creating, 2-9 
standards, 2-10 

versions 
creating, 2-32 to 2-37 
vectored, 2-6 


-BODY drawing, 1-11 
editing, 2-6 


BODY_TYPE property, 3-10 


bubble command, 2-30 
simulator primitives, 4-10 
timing primitives, 5-6 


|-2 


BUBBLE_GROUP property, 2-26 to 2-30 
and pipe character (|), 2-17 


bubble groups, 2-26 to 2-30 
asymmetrical, 2-28 to 2-29 


bubbled pins, 4-10, 5-6 
default, 2-30 
defining, 2-15 
standards, 2-13 
BUBBLED property, 2-29 
BUF primitive, 4-13, 5-24 
buffer, inverting, 5-24 
buffer primitives, 4-13 to 4-14 


bus-through pins, see pass-through 
pins 


C 


calculating delays and pulse widths, 
4-4 to 4-6 

CARRY SAVE ADDER primitive, 4-32 

change command 
default properties, 4-5 to 4-6 
modifying timing models, 5-34 
shortening body names, 2-8 
simulation primitives, 4-33 to 4-36 
timing primitives, 5-27 to 5-30 

checking 
bit width, 2-18 
pin loading, 3-28 

CHG primitive, 5-23 

chips.dat file, 3-30, 6-7, 6-9 

chips_ prt file, 1-12, 6-7, 6-9 
creating, 3-30 
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circle command, 2-11 


clock pins 
annotating, 2-20 
placing, 2-13 


cmplst.dat file, 3-30 


commands, see GED commands, 
UNIX commands 


common pins, multiple section compo- 
nents, 3-17 to 3-18, A-8 to A-10 


compact pin number syntax, 3-20 to 
3-21 


COMPARATOR primitive, 4-32 
Compiler error messages, 3-30 
compiler.cmd file, 3-30 

complement output, generating, 4-3 
completing new components, 2-41 


component 
cost specification, 3-10 
directory, 1-12 


components 
asymmetrical, 3-6 
pin 
names, 1-15 to 1-16 
numbers, 3-19 to 3-28, A-11 
attaching properties, 3-2 
completing, 2-41 
copying, 2-38, 3-4 
creating, 2-2 to 2-41 
multiple versions, 6-17 
library, 1-11 to 1-12 
versioning, 1-14 to 1-16 
modifying, 2-38, 3-31 
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index 


components (continued) 

multiple 
section, 1-15, A-7 to A-11 
version, 1-14 

sizeable, 1-15, 2-34 to 2-37 
numbering, 3-16 

support, creating, 6-2 to 6-19 

testing, 2-3 

vectored, 2-32 

zero-delay, 4-43 


configuration file (config.dat), 1-4 
connecting multiple outputs, 3-28 
connection points, wiring, 2-12 
connectivity files, 1-13 
connectors, creating, 6-2 to 6-14 
conventions 

library, 1-3 

signal name, 1-3 to 1-4 
copy command, 2-11 
copying components, 2~38, 3-4 
COST property, 3-10 
COUNTER SHIFT REGISTER primitive, 

4-28 to 4-29 


creating 

body shapes, 2-9 

components, 2-2 to 2-41 

connectors, 6-2 to 6-14 

grounds, 6-18 to 6-19 

libraries, 2-3 to 2-5 

library drawings, 3-6 

multiple physical models for one 
body, 6-8 to 6-10 

-PART drawings, 3-2 to 3-3 


Index 


creating (continued) 

physical 

models, 3-5 to 3-31 

part tables, 6-17 
resistor packs, 6-15 to 6-17 
simulation models, 4-7 to 4-46 
support components, 6-2 to 6-19 
timing models, 5-3 to 5-34 


D 


DIRECTORY commands, 1-17 to 1-18 
data-dependent delays, 4-5 


default 
drawing version numbers, 2-6 
properties, 2-25 
simulation properties, 4-33 to 4-36 


defining 
primitives, 3-2 
simulation models, 4-2 
timing models, 5—2 


delay 
calculations, 4-4 to 4-6 
rise and fall, 4-43 


DELAY_MODE directive, 4-43 


DELAY_MODEL directive, 5-32 to 5-33 


DELAY property, 5-32 to 5-33 
simulation models, 4-43 
testing, 7-8 
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delays 
body, 4-41 
data-dependent, 4-5 
modeling, 5-2 
pin-to-pin, 4-41 
DeMorgan equivalents, 1-15 
dependency files, 1-13 
design rules, simulation and timing 
models, 4-2 
determining 
disk space, 1-17 to 1-19 
file ownership, 1-18 
developing libraries, 1-2 
device loading, suppressing 
calculations, 3-28 
Of command, 1-17 
diagram command, 2-40 


directives 

simulation 
DELAY_MODE, 4-43 
MEM _STATE, 4-25 
PIN_DELAY, 4-45 
TIMING_CHECK, 4-33 

timing 
DELAY_MODEL, 5-32 to 5-33 
LATCH_ERR_MODEL, 5-11 to 5-13 
RISE_FALL_MODELS, 5-32 


directories 
component, 1-12 
library, 1-5 to 1-7, 2-3 
SCALD, 1-8 
DIRECTORY directive, 3-30 
disk space, 3-31 
determining, 1-17 to 1-19 
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Index 


display command, 2-8, 2-19 to 2-22 
invisible, 2-22 


dot command, 2-12 


drawing 
extensions, 2-6 
names, in operating system, 1-9 
pins, 2-11 
version numbers, default, 2-6 
DRAWING body, 3-2 
drawings 
-BODY, 1-11 
editing, 2-6 
“example of each...”, 1-7 
flat, 2-6 
library 
archiving, 3-31 
creating, 3-6 
modifying, 3-29 
.LOGIC, 1-13 
PART, 1-11 
creating, 3-2 to 3-3 
modifying, 3-4 
reference, 1-7 to 1-9 
.SIM, 1-11 
.TIME, 1-11 


Qu command, 1-17 


E 


EDGE TO EDGE primitive, 4-35, 5-30 
editing .BODY drawings, 2-6 

8 BIT DECODER primitive, 4-37 

8 BIT PRIO ENCODER primitive, 4-36 
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encoder and decoder primitives, 4-36 
to 4-37 


error-checking primitives, 5-27 to 5-30 
error messages, simulation model, 4-2 
errors, compilation, 3-30 

“example of each...” drawing, 1-7 
existing components, modifying, 2-38 


extensions 
drawing, 2-6 
lib, 1-8 
.prt, 1-8 


F 


fall delay, 4-43 


FALL property, 4-44, 5-33 
testing, 7-8 


FAMILY property, 3-8 

feed-through pins, see pass-through 
pins 

file names, 1-9 

filecopy command, 1-20 


files 

binary, 1-13 

chips.dat, 3-30, 6-7, 6-9 

chips_ prt, 1-12, 6-7, 6-9 
creating, 3-30 

cmplst.dat, 3-30 

compiler.cmd, 3-30 

configuration (config.dat), 1-4 

connectivity, 1-13 

dependency, 1-13 


Index 


files (continued) 
determining ownership, 1-18 
filecopy.cmd, 1-20 
master library (master.lib), 1-9 to 
1-10 
phys_dat, 1-12 
creating, A-1 to A-11 
pin number format, A-6 to A-11 
syntax, A-5 
physical information, 1-8 
protecting, 1-18 to 1-20 
startup.ged, 2-4 
transfer.log, 1-20 


find command, 1-18 to 1-19 

FLAG primitive, 4-40 

flat drawings, 2-6 

flip-flop size recommendations, 2-10 


foreign host library maintenance, 1-19 
to 1-20 


formats 
library, 1-3 to 1-4 
pin number, 3-13 to 3-21 
phys_dat file, A-6 to A-11 


G 


gates 
open collector, 4-5 
size recommendations, 2-10 
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GED commands 
arc, 2-11 
bubble, 2-30 


simulator primitives, 4-10 
timing primitives, 5-6 


change 


default properties, 4-5 to 4-6 
modifying timing models, 5-34 
shortening body names, 2-8 
simulation primitives, 4-33 to 4-36 
timing primitives, 5-27 to 5-30 


circle, 2-11 

copy, 2-11 

diagram, 2-40 

display, 2-8, 2-19 to 2-22 


invisible, 2-22 


dot, 2-12 

grid, 2-19 to 2-22 
library, 1-9 

move, 2-19 to 2-22 
note, 2-19 to 2-22 
pinswap, 3-25, 3-30 
property, 2-21, 3-2 
reattach, 2-31, 3-29 
section, 3-30 

set, 2-12 

show 


attachments, 2-17, 2—31, 3-29 
properties, 3-29 


signame, 2-16 


pass-through pins, 2-17 


smash, 2-38 to 2-39 
split, 2-8 

update, 1-13 
version, 1-14 

wire, 2-9, 2-11 
write, 2-31 
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generating complement output, 4-3 
grid command, 2-19 to 2-22 

grid settings, body, 2-7 

grounds, creating, 6-18 to 6-19 


groups 
bubble, 2-26 to 2-30 
asymmetrical, 2-28 to 2-29 
pinswap, 3-25 


H 


HAS _FIXED_SIZE property, 2-24 
high-asserted pins, 2-11, 2-15 
HIGH property, 4-35 


HOLD property 
simulation primitives, 4-33 to 4-34 
timing primitives, 5-27 to 5-30 


\I interface signal property, 4-7, 5-3 
IDENTITY primitive, 4-14, 5-25 
INPUT_LOAD property, 3-24 to 3-25 
input pins, placing, 2-13 

installing libraries, 1-18 

interface signal property (\I), 4-7, 5-3 
internal part numbers, assigning, 3-10 


inverting buffer, creating, 5-24 


10/1/89 


Index 


invisible 
pins, 2-14 
properties, 2-25 


1/O checking, suppressing calculations, 
3-28 


isolating outputs, 5-24 


J 


JK primitive, 4-15 


L 


labeling pins, 2-19—2-20 


LATCH_ERR_MODEL directive, 5-11 to 
5-13 


LATCH primitive, 4-16, 5-11 to 5-13 
latch primitives, 4-16 to 4-18 
LATCH RS COMP primitive, 4-18 


LATCH RS primitive, 4-17, 5-14 to 
5-15 


.lib extension, 1-8 


libraries 
accessing, 1-9 to 1-10 
copying components, 2-38 
creating, 2-3 to 2-5 
installing, 1-18 
maintaining on foreign hosts, 1-19 to 
1-20 
protecting, 1-18 to 1-19 
testing, 7-1 to 7-8 


Index. 


library 
components, 1-11 to 1-12 
versioning, 1-14 to 1-16 
conventions, 1-3 
development process, 1-2 
directory, 1-5 to 1-7, 2-3 
drawings 
archiving, 3-31 
creating, 3-6 
modifying, 3-29 
standards, 3-6 
formats, 1-3 to 1-4 
maintenance, 1-17 to 1-20 
organization, 1-5 to 1-16 
permissions, 1-18 to 1-19 


subdirectory contents, 1-7 to 1-9 


library command, 1-9 
~ load check properties, 3-28 


loading, device, suppressing 
calculations, 3-28 


LOCATION property, 6-6 


logic 
family, specifying, 3-8 
gate primitives, 4-11 to 4-12 


.LOGIC drawing, 1-13 
LOOKAHEAD primitive, 4-32 
low-asserted pins, 2-11, 2-15 


low—assertion character, 2-16 


LOW property, 4-35 
Is command, 1-18 


M 


maintaining libraries, 1-17 to 1-20 
on foreign hosts, 1-19 to 1-20 


master library file (master.lib), 1-9 to 
1-10 


MAX_DELAY property, 4-5 
MEM_STATE directive, 4-25 
MEMORY primitive, 4-25 to 4-27 


MIN PULSE WIDTH primitive, 4-35, 
5-29 


modeling delays, 5-2 


models 
delay and pulse width standards, 4-4 
to 4-6 
general design rules, 4-2 
physical 
creating, 3-5—3-31 
multiples for one body, 6-8 to 6-10 
simulation 
creating, 4-7 to 4-46 
defining, 4-2 
error messages, 4-2 
generating complement output, 4-3 
modifying, 4-46 
timing 
creating, 5-3 to 5-34 
defining, 5-2 
modifying, 5-34 
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modifying 
components, 3-31 
default simulation properties, 4-33 to 
4-36 
existing components, 2-38 
library drawings, 3-29 
.PART drawings, 3-4 
simulation models, 4-46 
timing models, 5-34 


move command, 2-19 to 2-22 


multiple 
component 
sections, 1-15 
versions, 1-14, 6-17 
outputs, connecting, 3-28 
physical models for one body, 6-8 to 
6-10 
section pins, 3-16 to 3-19, A-7 to 
A-11 


multiple-bit pins, see also vector pins 
and NEEDS_NO SIZE property, 2-23 
numbering, 3-15 


multiplexer primitives, 4-24, 5-21 to 
5~22 


N 


\NAC property, 2-18 
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Index 


names 
body, 2-20 
drawing, in operating system, 1-9 
pin 
adding, 2-16 
pass-through, 2-17 
sizeable, 2-36 to 2-37 
visible and invisible, 2-14 
signal, 1-3 to 1-4 
NEEDS_NO_SIZE property, 2-23, 2-32 
no assertion check, 2-18 
NO_IO_CHECK property, 3-28 
NO_LOAD CHECK property, 3-28 
no width check, 2-18 
non-bubbled pins, 2-30 
non-standard function primitives, 5-22 
to 5-27 
note command, 2-19 to 2-22 


notes 
on bodies, 2-19 to 2-20 
resizing, 2-19 


numbering pins, 3-11 to 3-21 
asymmetrical components, 3-19 to 
3-28, A-11 
common, 3-17 to 3-18 
compact syntax, 3-20 to 3-21 
phys_dat file, A-6 to A-11 
sizeable components, 3-16 


\NWC property, 2-18 


Index 


O PART_NAME property, 3-2 to 3-3 


bs PART NUMBER property, 3-10 
1 OF 8 DECODER primitive, 4-37 - PEOpery 


one-shots, 4-6 part numbers, assigning, 3-10 


open , parts, library, see components 
collector PASS TRANSISTOR primitive, 4-39 
gates, 4-5 
pins, annotating, 2-20 pass-through pins, 2-13 to 2-15 
emitter pins, annotating, 2-20 naming, 2-17 
placing, 2-13 


operating system file names, 1-9 standards, 2-14 


OR primitive, 4-12, 5-9 


inte, et permissions 
organizing libraries, 1-5 library, 1-18 to 1-19 
origin, body, 2-8 setting, 1-2 
OUTPUT directive, 3-30 PFALL property, 4-45 
OUTPUT_LOAD property, 3-24 phys_dat file, 1-12 
output pins, placing, 2-13 creating, A~1 to A-11 
pin number formats, A-6 to A-11 
OUTPUT_TYPE property, 3-27 to 3-28 syntax, A-5 
outputs | - 
isolating, 5-24 PHYS_DES_PREFIX property, 3-10 
multiple, connecting, 3-28 physical 


information 
adding, 3-5 to 3-31 
file (.prt), 1-8 


ownership, file, 1-18 


Pp phys_dat method, A-2 to A-4 
| transferring to Packager, 3-6 
PARITY primitive, 4-38 moc 
; creating, 3-5 to 3-31 
-PART drawing, 1-11 multiples for one body, 6-8 to 6-10 
creating, 3-2 to 3-3 part tables, 6-17 
modifying, 3-4 reference designator, 3-10 
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pin 
assertion, 2-15 
names 
adding, 2-16 
asymmetrical components, 1-15 to 
1-16 
attaching properties to, 2-17 
sizeable components, 2-36 to 2-37 
visible and invisible pins, 2-14 
number formats, 3-13 to 3-21 
phys_dat file, A-6 to A-11 
numbers 
assigning, 3-11 to 3-21 
multiple—-bit, 3-15 
phys_dat file, A-6 to A-11 
placement, 2-13 
properties 
adding, 3-22 to 3-28 
simulation, 4-41, 4-45 to 4-46 
standards, 3-24 
standards, 2-13 


PIN_DELAY directive, 4-45 
PIN_GROUP property, 3-25 to 3-26 
PIN_NUMBER property, 3-11 to 3-21 
pin-to-pin delays, 4-41 
pins 

adding, 2-11 

bubbled, 4-10, 5-6 

default, 2-30 


defining, 2-15 
standards, 2-13 
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Index 


pins (continued) 
common, numbering, 3-17 to 3-18, 
A-8 to A-10 
drawing, 2-11 
high-asserted, 2-11 
labeling, 2-19 to 2-20 
low-—asserted, 2-11 
multiple-bit 
and NEEDS_NO SIZE property, 2-23 
numbering, 3-15 
multiple section, 3-16 to 3-19 
numbering 
asymmetrical components, 3-19 to 
3-28 
phys_dat file, A-11 
common pins, A-8 to A-10 
compact syntax, 3-20 to 3-21 
multiple section, 3-16 to 3-19 
single section, 3-14 to 3-15 
pass-through, 2-13 to 2-15 
naming, 2-17 
power and ground, 3-9 
scalar, 3-14 
multiple section, A-7 
single section, 3-14 to 3-15 
tri-state, 3-28 
vectored, 2-23, 3-14, A-7 


pinswap command, 3-25, 3-30 
pipe character (|), 2-17 
placeholder properties, 6-6, 6-17 
placing pins, 2-13 


power and ground pin assignments, 
3-9 | 


POWER _PINS property, 3-9 


Index 


primitives 

ADDER, 4-30 

ALU, 4-31 

AND, 4-11, 5-8 

arithmetic, 4-30 to 4-32 

BUF, 4-13, 5-24 

buffer, 4-13 to 4-14 

CARRY SAVE ADDER, 4-32 

CHG, 5-23 

COMPARATOR, 4-32 

COUNTER SHIFT REGISTER, 4-28 to 
4-29 

defining, 3-2 

EDGE TO EDGE, 4-35, 5-30 

8 BIT DECODER, 4-37 

8 BIT PRIO ENCODER, 4-36 

encoder and decoder, 4-36 to 4-37 

error—-checking, 5-27 to 5-30 

FLAG, 4-40 

IDENTITY, 4-14, 5-25 

JK, 4-15 

LATCH, 4-16, 5-11 to 5-13 

latch, 4-16 to 4-18 

LATCH RS, 4-17, 5-14 to 5-15 

LATCH RS COMP, 4-18 

logic gate, 4-11 to 4-12 

LOOKAHEAD, 4-32 

MEMORY, 4-25 to 4-27 

MIN PULSE WIDTH, 4-35, 5-29 

multiplexer, 4-24, 5-21 to 5-22 


primitives (continued) 
1 OF 8 DECODER, 4-37 
OR, 4-12, 5-9 
PARITY, 4-38 
PASS TRANSISTOR, 4-39 
PRIORITY ENCODER, 4-36 
REG, 4-19, 5-20 to 5-21 
REG CKE, 4-23 
REG RS, 4-20, 5-21 
REG RS COMP, 4-21 
REG RS COMP 2, 4-22 
register, 4-19 to 4-23 
RES, 4-38, 5-25 
SCAN LATCH, 4-16 
SCAN LATCH RS, 4-16 
SETUP HOLD, 4-33, 5-27 to 5-28 


SETUP RISE HOLD FALL, 4~34, 5-28 


simulation, 4-2, 4-10 to 4-40 
and SIZE property, 4-44 

standard function, 5-8 to 5-22 

THRESHOLD, 5-26 

timing, 5-2, 5-6 to 5-30 

timing checker, 4-3, 4-33 to 4-36 

TRANSMISSION GATE, 5-26 

TS BUF, 4-14, 5-16 to 5-19 

ts bus, 5-17 to 5-19 

UNI PASS TRANSISTOR, 4-39 

UNI TRANS GATE, 5-27 

user-coded, 4-40 

XOR, 4-12, 5-10 


PRIORITY ENCODER primitive, 4-36 


non-standard function, 5-22 to 5-27 PRISE property, 4-45 
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properties 
ABBREV, 3-2 to 3-3 
added to pin names, 2-17 
ALLOW_CONNECT, 3-28 
attaching, 6-4 
to components, 3-2 
BIDIRECTIONAL, 3-25 
body, 2-21 to 2-30 
adding, 3-7 to 3-10 
BODY_TYPE, 3-10 
BUBBLE_GROUP, 2-26 to 2-30 
and pipe character (|), 2-17 
BUBBLED, 2-29 
COST, 3-10 
default, 2-25 
DELAY, 5-32 to 5-33 
simulation models, 4-43 
testing, 7-8 
FALL, 4-44, 5-33 
testing, 7-8 
FAMILY, 3-8 
HAS_FIXED_ SIZE, 2-24 
HIGH, 4-35 
HOLD 
simulation primitives, 4-33 to 4-34 
timing primitives, 5-27 to 5-30 
INPUT_LOAD, 3-24 to 3-25 
invisible, 2-25 
load check, 3-28 
LOCATION, 6-6 
Low, 4-35 
MAX_DELAY, 4-5 
\NAC, 2-18 
NEEDS_NO_SIZE, 2-23, 2-32 
NO_IO_CHECK, 3-28 
NO_LOAD_ CHECK, 3-28 


10/1/89 


Index 


properties (continued) 
\NWC, 2-18 
OUTPUT_LOAD, 3-24 
OUTPUT_TYPE, 3-27 to 3-28 
PART_NAME, 3-2 to 3-3 
PART_NUMBER, 3-10 
PFALL, 4-45 
PHYS_DES_PREFIX, 3-10 
pin 
adding, 3-22 to 3-28 
simulation, 4-41 
standards, 3-24 
PIN_GROUP, 3-25 to 3-26 
PIN_NUMBER, 3-11 to 3-21 
POWER _PINS, 3-9 
PRISE, 4-45 
PULSE_WIDTH, 4-6 
\R (replicate), 6-19 
RISE, 4-44, 5-32 
testing, 7-8 
SETUP, 4-33 to 4-34, 5-27 to 5-30 
signal interface (\I), 4-7, 5-3 
simulation, 4-41 to 4-45 
body, 4-41 to 4-42 
modifying defaults, 4-33 to 4-36 
pin, 4-45 to 4-46 
SIZE, 4-44, 5-33 
on version 1 body, 1-15 
testing, 7-7 
timing, 5-31 to 5-33 
TITLE, 3-2 to 3-3 
TRANSITION, 5-11 to 5-16, 5-21 
TS_BUF_TYPE, 5-16 to 5-19 
UNKNOWN_LOADING, 3-28 
VALUE, 6-17 


property command, 2-21, 3-2 


Index 


property standards, 2-26 
protecting libraries, 1-18 to 1-19 


.prt extension, 1-8 


pulse width calculations, 4-4 to 4-6 


PULSE_WIDTH property, 4-6 


R 


\R replicate property, 6-19 
reattach command, 2-31, 3-29 
reference drawings, 1-7 to 1-9 
REG CKE primitive, 4-23 

REG primitive, 4-19, 5-20 to 5-21 
REG RS COMP primitive, 4-21 
REG RS COMP 2 primitive, 4-22 
REG RS primitive, 4-20, 5-21 
register primitives, 4-19 to 4-23 
replicate property (\R), 6-19 
RES primitive, 4-38, 5-25 


resistor packs, creating, 6-15 to 6-17 


resizing notes, 2-19 
rise delay, 4-43 


RISE_FALL_MODELS directive, 5-32 


RISE property, 4-44, 5-32 
testing, 7-8 


ROOT_DRAWING directive, 3-30 
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S 


saving library drawings, 3-31 


scalar pins 
defining, 3-14 
multiple section, A-7 
numbering, 3-14 


SCALD directories, 1-8 

SCAN LATCH primitive, 4-16 
SCAN LATCH RS primitive, 4-16 
section command, 3-30 


sections, asymmetrical, see asymmetri- 
cal components 


separating body names and origins, 


SET commands, 1-18 to 1-19 
set command, 2-12 

setting permissions, 1-2 
settings, grid, 2-7 


SETUP HOLD primitive, 4-33, 5-27 to 
5-28 


SETUP property, 4-33—4-34, 5-27 to 
5-30 


SETUP RISE HOLD FALL primitive, 
4-34, 5-28 


shapes, body, creating, 2-9 
shortening body names, 2-8 


show command 
attachments, 2-17, 2-31, 3-29 
properties, 3-29 


SHOW DEVICE command, 1-17 
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showing library permissions, 1-18 to 
1-19 


signal 
interface property (\I), 4-7, 5-3 
name syntax, 1-3 to 1-4 
syntax, defining, 1-4 


signame command, 2-16 
pass-through pins, 2-17 


SIM drawing, 1-11 


simulation 

directives 
DELAY_MODE, 4-43 
MEM_STATE, 4-25 
PIN_DELAY, 4-45 
TIMING_CHECK, 4-33 

models 
creating, 4-7 to 4-46 
defining, 4-2 
delay and pulse width standards, 

4-4 to 4-6 

error messages, 4-2 
general design rules, 4-2 
generating complement output, 4-3 
modifying, 4-46 

primitives, 4-2, 4-10 to 4-40 
ADDER, 4-30 
ALU, 4-31 
AND, 4-11 
and SIZE property, 4-44 
BUF, 4-13 
CARRY SAVE ADDER, 4-32 
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Index 


simulation primitives (continued) 


COMPARATOR, 4-32 
COUNTER SHIFT REGISTER, 4-28 
EDGE TO EDGE, 4-35 

8 BIT DECODER, 4-37 

8 BIT PRIO ENCODER, 4-36 
FLAG, 4-40 

IDENTITY, 4-14 

JK, 4-15 

LATCH, 4-16 

LATCH RS, 4-17 

LATCH RS COMP, 4-18 
LOOKAHEAD, 4-32 
MEMORY, 4-25 

MIN PULSE WIDTH, 4-35 
multiplexer, 4-24 

1 OF 8 DECODER, 4-37 
OR, 4-12 

PARITY, 4—38 

PASS TRANSISTOR, 4-39 
PRIORITY ENCODER, 4-36 
REG, 4-19 

REG CKE, 4-23 

REG RS, 4-20 

REG RS COMP, 4-21 

REG RS COMP 2, 4-22 

RES, 4-38 

SETUP HOLD, 4-33 

SETUP RISE HOLD FALL, 4-34 
TS BUF, 4-14 

UNI PASS TRANSISTOR, 4-39 
user—coded, 4-40 

XOR, 4-12 


Index 


simulation (continued) standards (continued) 
properties, 4-41 to 4-45 pin property, 3-24 
body, 4-41 to 4-42 property, 2-26 
FALL, 4-44 startup.ged file, 2-4 
ee Pe faults, 4-33 to 4-36 storing library drawings, 3-31 
pin, 4 “45 to 4-46 subdirectories, library, 1-7 to 1-9 
PRISE, 4-45 support components, creating, 6-2 to 
RISE, 4-44 6-19 
single section pins, numbering, 3-14 to supressing 
3-15, A-7 device loading calculations, 3-28 
as V/O checking, 3-28 
SIZE-1 in pin names, 2-36 
| syntax 
SIZE property, 4-44, 5-33 compact pin number, 3-20 to 3-21 
on version 1 body, 1-15 phys_dat file, A-5 
testing, 7-7 signal name, 1-3 to 1-4 
size recommendations for bodies, 2-10 
sizeable components, 1-15, 2-34 to T 
2-37 ; testing 
numbering, 3-16 components, 2-3 
smash command, 2-38 to 2-39 libraries, 7-1 to 7-8 
split command, 2-8 THRESHOLD primitive, 5-26 


standard function primitives, 5-8 to sels drawing, I-11 
5-22 timing 
checker primitives, 4-3 


standards directives, LATCH_ERR_MODEL, 5-11 
annotation, 2-20 to 5-13 
body models 
origin, 2-8 creating, 5-3 to 5-34 
shape, 2-10 defining, 5-2 
grid, 2-7 delay and pulse width standards, 
library drawing, 3-6 4-4 to 4-6 
pass-through, 2-14 general design rules, 4-2 
pin, 2-13 modifying, 5-34 
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Index 


timing (continued) 
primitives, 5-2, 5-6 to 5-30 
AND, 5-8 
BUF, 5-24 
CHG, 5-23 
EDGE TO EDGE, 5-30 
error-checking, 5-27 to 5-30 
IDENTITY, 5-25 
LATCH, 5-11 
LATCH RS, 5-14 
MIN PULSE WIDTH, 5-29 
multiplexer, 5-21 
non-standard function, 5-22 
OR, 5-9 
REG, 5-20 
REG RS, 5-21 
RES, 5-25 
SETUP HOLD, 5-27 to 5-28 
SETUP RISE HOLD FALL, 5-28 
standard function, 5-8 
THRESHOLD, 5-26 
TRANSMISSION GATE, 5-26 
TS BUF, 5-16 
UNI TRANS GATE, 5-27 
XOR, 5-10 
properties, 5-31 to 5-33 

TRANSITION, 5-11 to 5-16, 5-21 
TS_BUF_TYPE, 5-16 to 5-19 


TIMING_CHECK directive, 4-33 

timing checker primitives, 4-33 to 4-36 
TITLE property, 3-2 to 3-3 

transfer.log file, 1-20 
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TRANSITION property, 5-11 to 5-16, 
5-21 


TRANSMISSION GATE primitive, 5-26 


tri-state 

buffer, see TS BUF primitive 

bus, see TS BUS primitive 

mode, TS BUF primitive, 5-16 to 5-19 

pins, 3-28 

annotating, 2-20 

truth table abbreviations, 4-10, 5-7 
TS BUF primitive, 4-14, 5-16 to 5~19 
TS_BUF_TYPE property, 5-16 to 5-19 
TS BUS primitive, 5-17 to 5-19 


U 


UCPs, see user—coded primitives 


ULTRIX commands, see UNIX com- 
mands 


UNI PASS TRANSISTOR primitive, 4-39 
UNI TRANS GATE primitive, 5-27 


UNIX commands 

Of, 1-17 

du, 1-17 

filecopy, 1-20 

find, 1-18 to 1-19 

Is, 1-18 
UNKNOWN_LOADING property, 3-28 
update command, 1-13 


user—coded primitives, 4-40 


Index 


V 


VMS commands 
DIRECTORY, 1-17 to 1-18 
SET, 1-18 to 1-19 
SHOW DEVICE, 1-17 


VALUE property, 6-17 


vector pins, See also ae pins 
defining, 3-14 
multiple section components, “A-10 
numbering, 3-14 
single section components, A-7 


vectored 
body versions, 2-6 
components, 2-32 
pins, 2-23 
version command, 1-14 
version numbers, default, 2-6 


versions 
components, multiple, 1-14, 6-17 
creating, 2-32—2-37 
library component, 1-14 


I-18 


visible and invisible pins, 2-14 


W 


width checking, 2-18 
wire command, 2-9, 2-11 


wire-or mode, TS BUF primitive, 5-16 
to 5-19 


wiring 
bodies together, 2-13 
connection points, 2-12 


write command, 2-31 
X 
XOR primitive, 4-12, 5-10 


Z 


zero-delay components, 4-43 
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